Roles- A case study in web applications

TLDR: We implemented a mechanism of supporting various roles and permissions, but a properly maintained library should have been our first choice. Not because of the inherent lack of features in our library or ease of changing rules based on business logic, but mostly due to the ease of use of off the shelve component.

Every application requires a different type of users having different capabilities, powers (or lack of). A very minimal setup up would require normal users and admin users. Admin users can manage normal users and their data if required to be. If we take this setup, one step above, we can add primarily two things (a) More layered-roles and (b) overlapping permissions. While first can be implemented easily, it’s the second which can provide itself to be a hurdle. There are two sub-objectives to consider when we are implementing overlapping roles

1. Business Logic is easy to understand.
2. Making sure that changing code should be feared upon.

So to give an overall perspective. We have 5 types of application users.

1. Developer: A user with almost god mode power.
2. Level 1: Basic user
3. Level 2: Application User sitting above Level 1.
4. Level 3: Application User sitting above Level 2.
5. Level 4: Application User sitting above Level 3.

Now a user who is not a developer will have at least 1 application user from (2-5). He can have 4 roles (excluding Developer role).

So this level of complexity creates some hurdles. First and foremost was handling overlapping of roles with the Business Logic. So to alleviate this problem, we had to create two layers of logic. The first layer contained the views and data required for the view. It’s important to know that input information should be kept to a minimum, in order to use it wherever required. The second layer was used for filtering the Domain Users. For the project, Laravel provides excellent Middleware. Though, one must keep in mind that it is operated at the HTTP layer.  So this is the overall gist on how to do this. But let us deep dive on the first layer in order to attain the two sub-objectives.

For the first layer, we should have some form of abstraction.

Backend Side for Web applications.

Backend Classes:

Even though Laravel does the heavy lifting for CRUD operations, it’s better to have your own classes leveraging Laravel for CRUD operations. It will yield two main advantages

1. Incorporate business logic on the elementary objects. For example, for inventory, the count should not be in a fraction and at the minimum, it should be 0. Now in this simple example, it’s fair to say that this rule should be global for every inventory. Now, this global logic if true should be lowest backend class. It should primarily deal with primitive objects (that is Array, strings, and numbers), for ease of development and testing.
2. Provides project-wide code reusability. (This will come in handy later on)

View Classes:

As the name suggests, it just generates views. Now though it contains some logic, more or less it uses the backend classes for the output.

Process Classes:

Now similarly, like the view, they often use Backend classes for the low-level work. Now unlike View Classes, these classes are used for checking or executing. Now if the task at hand is a simple deletion, then no need for creation of Process Classes. But if the task is more complicated than that, then the Process Class is written.

Note that in any of the above-aforementioned classes, we should not deal with any form of ACL.

So just to recap again, write low-level classes for CRUD for a single model. Then on top of it, write two sets of classes View classes and Process classes for helping business logic(if required).

As for roles, we should use middleware.

Now let’s see the issues with such a methodology. First, we have achieved the ACL with the help of middleware. Though this is not glued to business logic, however, it lies with Http layer (again nothing inherently wrong with it, except it, should be independent). Secondly, a better approach would be to write permissions and then build up roles based on these permissions. This would have helped us slightly more with modular code.