I'm making a school management system using CodeIgniter framework of PHP.
I'm stuck in a situation where I want to make super user that the Principal of school will use and manage new students and teachers and other stuff related to school. He will obviously login first and then manage other details.
i. I want to know where should I place this super user. In database or hard coded it's username and password? (I know it is not good to make a table which would have just one row)
ii. And if I should "hard code" it then where should I write it's login detail so that it's secure.
You should keep the data in database keeping relation with multiple tables which wil help you later for givings roles to the users. Such as:
tbl_user -> Will contain users information
tbl_roles -> Contains the roles of the user
tbl_user_permission -> Would contain the user given permission to certain user.
Hence, the super user/ admin will have all the contained permissions whereas the super admin has also the facility to gib certain permission to other users as well.
Depending upon your SMS it will contain multiple users and different levels of users, so it is probably best to entry the data into database. Dividing into multiple tables.
Related
I have done a lot of reading on this but nothing stands out. I already have a authentication and authorisation system that can handle multiple guards and user roles (user, admin, super admin etc.)
I am trying to find out what is the best way to separate the system into totally separate accounts which have the following;
No login section
Landing page. Anyone can see without login.
Admin Section
Admin side of the system has a super-admins and then multiple admin-users.
These users can see all data from every user who has an account on the client side.
Client Section
Each user account has an owner who deals with billing, their own user admin etc.
Each client account also has a number of users (admin-users, editor-users etc.) with varying permissions.
Users on this side should only ever be able to see their own accounts data. They should not be able to ever see other accounts data.
Before Laravel, I would have an accounts table and assign a unique key to each account. Then a separate users table would contain the user along with their account key.
All database tables from this point onwards (posts, products, shipments etc.) would also have this key to ensure that the user account could only see their own data.
On top of this there would be permission tables, for granular control of what each user from either side can see.
Is my original way still suited to Laravel or is there a better way?
To separate out the accounts into their own "ecosystems" within the same code base is called multi tenancy. Basically, you scope your applications queries based on the user id and/or role which limits the available data to any given user.
Have a look at the Landlord Package.
In a very basic summary, what it does is add a where('tenant_id, auth()->id()) clause to every applicable query.
You can of course either omit the clause entirely for super admins to access all data, or apply even tighter constraints, say by adding a check for the user's role in addition to the clause, further limiting what a user can access within their respective account/organization/group etc.
Scoping can be done by any kind of relationship, you're not necessarily limited to the authenticated user's id. If your application has organizations for multiple user's you can use the organization id.
Multiple tenant ids is also possible, where a user must belong to an organization and a certain division within that organization.
Another package I've used previously is Hyn's multi-tenant.
We have same project as you mention . We create a company table and put it on the top of the hierarchy.
Then add new field all tables as company_id
And manage models over Policy -> https://laravel.com/docs/5.8/authorization
I hope this help
Some basics:
I am using a user authenticated login to an admin system that allows users to add customers, and an array of info about customers, including geo-location information for use with GMap API. My goal is to allow users to add each other for networking purposes in regards to their customer clientele. I am wondering what the best approach at building the database/table structure should be.
At the moment, I have a database called pbud1 with a users table and a customers table. For networking, my idea is to use the users unique id-> uid as an identifier for their network. Then add a table when a network is instantiated by the user, naming the table network_+the id from their 'users' table, ex: network_uid where pbud1.network_uid = pbud1.users.uid. So if the user has an id of 6 it would be network_6. Then within the new table "network_6", place relevant information on each row about each user that is added to that users network, ie; nid(key/ai) net_user_id(uid), geo_location, business, name, etc...
Goal: Allow each user within their parent network to access that specific user.parent customers information. Suggest users to user.parent due to geo_location of customer base between related users.
Honestly the semantics are not so important here as the structure and build of the DB table relationship in regards to the ability for networked users to access each others customers information.
Any assistance on approach would be greatly appreciated!
I'm building a PHP application where users can design products and then check out to a shopping cart if they want to.
To let the user create a design, I need to assign a user ID and design ID to store it in the database.
There are two types of users who can build designs:
registed users. To take care of this, I have no problem.
non-registered users. These are guest visitors who might play around with product designs, and then when they hit check out, only then will I ask them to sign up. But in order to store their designs, I do need to have some kind of user ID.
I thought of using a timestamp as this user's ID, but what if two users in different parts of the world create designs at the same time? What's a good strategy for generating IDs for temporary/guest user accounts? I don't just mean temporary in the php session sense, because I want them to be able to access their partially saved designs later on if they visit the site again, just like any other registered user. I will only ask them to sign up before checking out for payment.
A simple approach might be:
Use a single user table (for registered users and guests)
Assign a "user_type" flag. E.g. registered/guest
Use the table primary key or other unique value for both "types" of user
When guests check out later on, switch their "user_type".
Store other related customer details in a separate table.
My RealEstate PHP Application have following user groups,
Admins,
Moderators
Agents
i want to specify following permission to the following users.
Admins - >
Can Create Moderators,
Can Create Agents,
Can Insert Properties,
Can Update Properties,
Can Delete Properties
Hence an Admin will have all the privileges in short an Admin here will be superAdmin
I want to assign limited privileges to the moderator and hence to the agents.
i am confused on how to Create a Database for this and also on how to implement it in my PHP Application.
thank you
It sounds like you are going to need a role-based access control system. Developing one is not
really a trivial task, so as already suggested, finding a framework or ready-made class that does
the job would be a worth while start.
Role Based Access Control
http://www.tonymarston.net/php-mysql/role-based-access-control.html
http://www.sqlrecipes.com/database_design/fine_grained_role_based_access_control_rbac_system-3/
http://www.sitepoint.com/forums/showthread.php?threadid=162027
You should create a table wher you have to define all type of role.
and one table for users
relate different roles to different user Via linking two tables.
and some thing like this ......
The way that I have done this in the past was to create a users table in the database that had an access level (Admin, Moderator, and agents).
Then if you have a menu system, implement a check to see what privileges are needed for what links... Admins will see all links, Moderator will only see links he/she is supposed to, and agents will only see what they are supposed to see.
Also on the pages that you may want to restrict users you will want to check for the users access level. If they pass, they will see the page, if not, they will be redirected or a javascript error will need to pop up.
Something like the access level may do you some good to store it in a cookie as you can cut down your calls to your database.
Hope this helps,
Mike
I am creating an web application and I at the point that i am starting to make backend choices. Now there are a lot of ways to go with this, so I am looking for some good points and back practices.
Some of the question i have involve:
Should i make a seperate table in the db for admin users
Should i extend make some classes to load the admin data and the normal data, or make seperate classes for the admin section
Where can i get some information on making different types of users
Just some best practices for a backend
My application is written in PHP with an MySQL database.
Keeping a separate table for admin users is nice, but only if those admin users aren't "regular" users as well - otherwise you'll step on your own toes trying to keep usernames/IDs unique but somewhat connected.
A couple things to consider:
Apache authentication (or Windows accounts on IIS) for admin users. Separate system entirely, but allows for overlap - a regular user can be a regular user, but they can't access any admin functionality until they authenticate through the browser. Works fine if you only have a couple specific kinds of user role (e.g. member & administrator only).
All users in one table, but with roles and permissions separate. This is the most flexible because you can get as granular as you need. For example, any user can "post comments," while an admin can "delete comments" and "ban users," but a moderator can only "suspend comments" and "mute users." As you add new features, it's simply a matter of implementing some new permissions & assigning them to the roles. Drupal's access control does this really well, worth a close look.
A good way to do it is to add a new field in the users table for 'rank' in order to differentiate between regular users and staff members, and possibly between the different staff member levels such as moderator, admin, etc. if you need it. Because an administrator should be able to perform all functions that a user can. Use
class Admin extends User { }
if you want to add additional functionality specific to staff members.
As for backend functions, that depends on how your site is set up. If you're using a framework, you can just add new functions to existing controllers and restrict access only to users with a certain rank.
For example, you might have a controller for ForumPost objects, but calling the ForumPost delete() function would require the user to be a forum moderator.
If you're not using a framework, you'll probably have to make your own pages for each backend function you need.