Problem Statement -

Imagine a corporate hierarchy where users with higher authority will have privileges over the role with lower authority.

Based on their privileges and role, the features of the applications will be available to the users.

Consider these 4 roles.
Senior manager > manager > software engineer > intern.

In this order, the intern will have the least privilege and the senior manager will have the most privilege.

A higher authority can update the role of the lower authority to any level lower than it, for example, a Senior manager can promote an intern to the manager directly.

If the lower authority makes any change that requires approval, the task should be in a pending state and anyone above its role should be able to approve it.

Based on this, design a web application for role-based users. Discuss the following features

• How do you dynamically show the web application features based on the user’s role?.

• How do you handle the privileges and authority?

  • How do you extend the application so that the role names can be dynamic?

Things that you will handle in the frontend and things that you expect from the backend.

How do you dynamically show the web application features based on the user’s role.?

There are two levels at which we can add the restrictions.

• Route level restriction – where users with a certain role can access certain routes.

• Feature level restriction – where users with certain roles and privileges can perform the actions.

For example, an intern can view the employee hierarchy in the web application but cannot perform any actions whereas a senior manager can view and also do certain actions like promoting or demoting.

Thus after discussing with the product managers and getting clarity on the roles and their privileges, we can design a complete hierarchy chart with the features set and convert this to configuration to dynamically add restrictions.

Based on the configurations add the restrictions at the route level and the features level. Call this configuration API before login in and cache it.

Once the user is logged in, based on their role, use the configuration details and dynamically render the view.

For route-level restrictions, create a middleware that will check if the user has the authority to access the route and then allow it.

Feature-level restrictions will answer the second point “How do you handle the privileges and authority.”?

How do you handle the privileges and authority?

This is going to be the most complex part of the application. It requires careful implementation at the component level, module level, and sub-page level.

For example, The Pending request module will be visible to everyone except for Interns,

A software engineer can only view the intern’s requests, a manager can view both the software engineer’s and the intern’s requests, and so on.

To make it completely dynamic, we will have to rely on the configuration and one way we can do it is to create the components for different roles and abstract the logic, this will minimize the chances of error with the multiple conditions and every user role will have its own component level implementation.

Note – “Expect a follow-up question, where you have to create a component to show the working. (Low-level design)”.

How do you extend the application so that the role names can be dynamic?

We can have alias mapping and can use the alias labels for the same level. This way roles and privileges will remain the same but the labels could be different.

Things that you will handle on the front end and things that you expect from the back end.

The session management of the user will rely on the backend and the configuration as well. The configuration will be constructed as a JSON and will be returned from the backend using which the frontend will dynamically render the views.

A token-based authorization mechanism would be the best suited as whenever a user’s role is changed, its session/token will be expired, if that user is currently logged in the system, on its next API call, 401 unauthorized will be returned and we can have the API interceptor that will log out the user.

There should be checks to validate the privileges both at the backend and the frontend to be extra sure.

The configuration JSON should be the single source of truth for both the parts to minimize the chances of error.

Hope You Enjoy Reading!!!!