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!
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
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?
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
MySQL Server
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
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.