Logic for Access Levels

APD Toronto
APD Toronto used Ask the Experts™
on
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:

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!
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Principal Data Engineer
Commented:
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.
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.
APD TorontoSoftware Developer

Author

Commented:
I'm just seeking ideas on how to structure my table(s).
Most Valuable Expert 2011
Top Expert 2016
Commented:
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?

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial