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.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
As you build this, whatever design you choose, make a google search for "cyclomatic complexity" and read all the references. Then make a google search for "unit testing" and read those, too. If you cannot write unit tests for your application, it's too complex to ever be tested at the application level, and it will contain undiscovered latent run-time errors that will make your existence a living hell. I've seen this happen, and it always starts with some kind of complicated, but integrated, set of client roles. So let's try to think through a design that avoids complexity as much as possible.
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.
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.
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.
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial