Looking for suggestions on different user roles best design practices
I am going to have about 3 or 4 different access levels and some content should be available to some users and some not. I am looking for some advice on how best to do this.
For example, I thought of when a user logs in, they are presented with different navigation panels depending on their level of access. So, there could be a switch statement which would then include different navs like:
nav-management.php
nav-operator.php
nav-admin.php
etc.
Or, is it common practice to show one navigation for all users but when a user clicks on a certain item a check is done on their access level and if not authorised, a message can popup stating they they aren't authorized to access that.
I have a similar question around the dashboard. I could use the switch statement again and display different dashboards depending on the access level of the user or code each widget on the dashboard to only display for certain access levels.
I am not sure if there is a right or wrong way of doing this but any advice would be appreciated.
For example, I thought of when a user logs in, they are presented with different navigation panels depending on their level of access. So, there could be a switch statement which would then include different navs like:
nav-management.php
nav-operator.php
nav-admin.php
etc.
Or, is it common practice to show one navigation for all users but when a user clicks on a certain item a check is done on their access level and if not authorised, a message can popup stating they they aren't authorized to access that.
I have a similar question around the dashboard. I could use the switch statement again and display different dashboards depending on the access level of the user or code each widget on the dashboard to only display for certain access levels.
I am not sure if there is a right or wrong way of doing this but any advice would be appreciated.
Asked:
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.
There is no best practice that I am aware of - too many variables for that.
For instance one approach might be one nav with a framework that renders out only the options that are available to that level of access. You have a function getMenuItems() - this queries a database and builds a Nav from the security permissions and available menu items
Or
You have multiple menus defined and then use conditional statements to include one or the other.
Or
You have a framework that directs the user to a completely different branch of your code that deals with that role so each role is entirely ringfenced in terms of what they can access but share functionality through the engine.
There are many factors that drive the decision on this - not the least of which is the architecture of your system, the nature of your user base and the complexity of your role system.
If I would you I would look at this in terms of what is the easiest and most extensible method for achieving the role based access you want.
One thing I would not do is show options that a user does not have access to - there is absolutely no benefit in that - it creates confusion for the user and provides information to lower ranked users on what functionality is available which could encourage attempts to circumvent your security.
Show only what they need to see.
For instance one approach might be one nav with a framework that renders out only the options that are available to that level of access. You have a function getMenuItems() - this queries a database and builds a Nav from the security permissions and available menu items
Or
You have multiple menus defined and then use conditional statements to include one or the other.
Or
You have a framework that directs the user to a completely different branch of your code that deals with that role so each role is entirely ringfenced in terms of what they can access but share functionality through the engine.
There are many factors that drive the decision on this - not the least of which is the architecture of your system, the nature of your user base and the complexity of your role system.
If I would you I would look at this in terms of what is the easiest and most extensible method for achieving the role based access you want.
One thing I would not do is show options that a user does not have access to - there is absolutely no benefit in that - it creates confusion for the user and provides information to lower ranked users on what functionality is available which could encourage attempts to circumvent your security.
Show only what they need to see.
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
Thank you both for your answers. I would like to award both as best answers but we know this isn't possible ( I did request it). So, I don't know how to choose a "best solution". Perhaps I will just have to take turns. I will see if I can find who I awarded best answer last time I had this problem and then just do the opposite this time.
After a quick look it seems like I awarded Ray with best answer for my MVC question. So, this time can be Julian and next time in this situation, Ray again :)
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
PHP
From novice to tech pro — start learning today.
-
Business CommunicationCertification: PMI ACP Project Management Institute Agile Certified Pra… 283 lessons
-
Microsoft ApplicationsCertification: MOS Microsoft Office Specialist - PowerPoint 2010… 203 lessons
-
Microsoft ApplicationsCertification: MOS Microsoft Office Specialist - Word 2013 Part … 120 lessons
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.
Please refer to this article.
https://www.experts-exchange.com/articles/2391/PHP-Client-Registration-Login-Logout-and-Easy-Access-Control.html
In the article there is some reference to using the access_control() function to test whether a client is logged in. It uses a parameter to get a binary response - either the client is logged in or not. You can expand this concept by defining a set of constants, and passing the constants as an argument when you call the access_control() function. Different constants would be associated with different roles.
You can call the access_control() function once at the top of the page and simply not show the pages that do not suit the client's roles.
If you're going to make this more complex, such as adding different site navigation links for different client roles, you might want to build a separate navigation module, something that you can require_once() in the course of building the response documents. The separate navigation module will test the client role, and only return a set of navigation links that are appropriate to that role.
One thing to watch out for, and avoid as much as possible, are switch() or if() statements that make general logic decisions based on client roles. Isolate, compartmentalize, encapsulate - whatever you have to do - to avoid leaking the knowledge of roles into the logic of the web site. Some (probably myself included) would counsel you to use separate subdomains for separate roles, so that this kind of complex branching logic can be avoided entirely.