Logic for Access Levels
Hi Experts,
Can anyone give my any ideas on how I can about creating Login Access Levels that admins can use to specify which access level can access which module for a PHP/MySQL application.
There is a pre-defined list of ~25 modules going up to 2 levels deep, for example:
As you can see there are modules, and sub-modules, but there won’t be sub-sub-…-modules… just the 2 levels. I tried to make the 2 reports indented to demonstrate sub-levels, but EE won't let me.
To further complicate it, each may have either yes/no as options, or Full Access / Read-Only / No Access as options.
I guess, I’m looking for ideas on how to structure my DB for this, so when admins create a new level, I can use it as a template, then save the selections for each level.
As for the actual restriction, that I have figured out partly… I imagine that each module would be a database record, so I would pull all records associated to the user’s level, store it into a Session Associative array, then for each module do an If statement.
Any ideas would be greatly appreciated!
Can anyone give my any ideas on how I can about creating Login Access Levels that admins can use to specify which access level can access which module for a PHP/MySQL application.
There is a pre-defined list of ~25 modules going up to 2 levels deep, for example:
Orders
Login Levels
Reports
Today’s Sales
Monthly Sales
As you can see there are modules, and sub-modules, but there won’t be sub-sub-…-modules… just the 2 levels. I tried to make the 2 reports indented to demonstrate sub-levels, but EE won't let me.
To further complicate it, each may have either yes/no as options, or Full Access / Read-Only / No Access as options.
I guess, I’m looking for ideas on how to structure my DB for this, so when admins create a new level, I can use it as a template, then save the selections for each level.
As for the actual restriction, that I have figured out partly… I imagine that each module would be a database record, so I would pull all records associated to the user’s level, store it into a Session Associative array, then for each module do an If statement.
Any ideas would be greatly appreciated!
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I use similar logic to allow our users to see and interact with different parts of our system. Without going into it fully (company policy) I can give you a basic idea.
Firstly, you need to create policies for each and every api call your system will make. In your api/code before actually making any requests you should know who is logged in and what their permission levels are. You make a quick permission check for the request being made and the check will take care of querying the database to see which user types can access that command/request. If the logged in user type passes permission you make the request and return the response - or you send back a permission error.
As for the user types, you setup a user-type table and for each new user created you assign them a user-type which will be recorded in the table.
For example: s_admin, admin, user, guest etc..... however you want to set that up.
You have to be careful to make sure an admin level user can not make changes to user-type that is above their own level.
Hopefully that will give you some idea as to what I have done.
Firstly, you need to create policies for each and every api call your system will make. In your api/code before actually making any requests you should know who is logged in and what their permission levels are. You make a quick permission check for the request being made and the check will take care of querying the database to see which user types can access that command/request. If the logged in user type passes permission you make the request and return the response - or you send back a permission error.
As for the user types, you setup a user-type table and for each new user created you assign them a user-type which will be recorded in the table.
For example: s_admin, admin, user, guest etc..... however you want to set that up.
You have to be careful to make sure an admin level user can not make changes to user-type that is above their own level.
Hopefully that will give you some idea as to what I have done.
Hi,
I had similar project and I end up using this script:
http://codecanyon.net/item/advanced-security-php-registerlogin-system/5282621
The code is very good and clear, it is not expensive, it's using PHP PDO JSON Bootstrap.
The support is very good too, plus it's cover security which is very important.
here is the documentation: http://mstojanovic.net/as/documentation/
The dev will update the script soon but this time using Laravel framework with lot more features, you can ask presale question to see if this will fit your future needs.
I had similar project and I end up using this script:
http://codecanyon.net/item/advanced-security-php-registerlogin-system/5282621
The code is very good and clear, it is not expensive, it's using PHP PDO JSON Bootstrap.
The support is very good too, plus it's cover security which is very important.
here is the documentation: http://mstojanovic.net/as/documentation/
The dev will update the script soon but this time using Laravel framework with lot more features, you can ask presale question to see if this will fit your future needs.
In a years-old article, we show the design pattern that allows us to protect a "resource" with a single line of PHP code. In this example, a resource == a web page, but it could just as easily be an object instance of a class, or a database access module, or an API entry point, etc. While there is a lot more to the article than just resource protection, that's the important take-away for this question.
http://www.experts-exchange.com/articles/2391/PHP-Client-Registration-Login-Logout-and-Easy-Access-Control.html
Extending that idea beyond the access_control() function is a relatively trivial exercise. Think about how we might build functions "red_access_control()" or "blue_access_control()" etc. The resource to be protected would be color coded, and the protection algorithm would identify the resource colors, as well as the client colors. If there is a match (ie, both have "red") then the resource can be exposed to all the activities allowed by the "red" permissions, etc. This implies a design that becomes easily extensible, since each client and resource will be represented by a database record. Then all we have to do is look for a match. Access of any sort is disallowed by default. The "owner" of the resource writes permission rules to expose the resource to different color-coded clients.
Does that make sense?
http://www.experts-exchange.com/articles/2391/PHP-Client-Registration-Login-Logout-and-Easy-Access-Control.html
Extending that idea beyond the access_control() function is a relatively trivial exercise. Think about how we might build functions "red_access_control()" or "blue_access_control()" etc. The resource to be protected would be color coded, and the protection algorithm would identify the resource colors, as well as the client colors. If there is a match (ie, both have "red") then the resource can be exposed to all the activities allowed by the "red" permissions, etc. This implies a design that becomes easily extensible, since each client and resource will be represented by a database record. Then all we have to do is look for a match. Access of any sort is disallowed by default. The "owner" of the resource writes permission rules to expose the resource to different color-coded clients.
Does that make sense?
Premium Content
You need an Expert Office subscription to comment.Start Free Trial