The concept of site user rights how to do?

Question

CMS

Good afternoon, I have my own CMS / Product, which does not (yet) have a rights system.
There is a need to do the following:
Entering the site, the user has several items (modules / plugins), I will call them fictitious names so that I do not have to write documentation.
The user has one or more organizations (selection list)
Organization X:
Plugin A -
you can create / delete / change "something" --
each "something" has n-th number of input / textarea / checkbox, etc.
Plugin B
... see above...
There is a need to create a system of rights up to the input.
those. a user can CRUD an entire organization or a
user can CRUD Plugin A
a to Plugin B can change only one input.
*CRUD - Create Read Update Delete
I'm looking for how to plan / do it all right.
Thought to follow the "chain" the
user has the right:
OrganizationX.* | CRUD
OrganizationX.PluginB.something.Input | RU
and here m:n user_right
At the same time, each controller must know that it belongs to the Plugin and then:
if a request from user A from Organization B to Plugin C and change the Checkbox, then a request is made to the database
for OrganizationB.PluginC.something. Checkbox and since there is no such thing, an exception or false will be thrown
. I would like to hear opinions, experience or suggestions for improving or changing this concept.
Development is on laravel, more precisely, it will correspond with the current version.
Thanks in advance.

Answer 1

it's called RBAC

Answer 2

as noted above RBAC or ACL

Answer 3

Most performance optimizations usually come down to doing hard work when you need to get results quickly, and generally reduce the amount of work.
And most of the optimizations for reliability, development speed, and generally the cost of ownership of the code usually come down to its reduction and simplification.
Therefore, in any case, you will have to choose either-or at some point.
At the expense of the productive access layer, I usually do something like this:
Here I have objects whose access settings affect other objects, access to which is also configured (I will use folders as an example).
When changing the folder access settings for each subfolder, I calculate the effective access settings. Those. Since access restrictions on the parent folder are added to those on the child folder, effective child access settings include both those restrictions and those.
So for each folder, I store not only the initial access settings that the user set specifically for this folder, but also all the prohibitions of all parent folders up to the root.
So when deciding whether to give access to each object, I do not need to load the access settings of all parent objects from the database. But for then changing access settings slows down. Usually it's ok.
If that's not enough, here's how I optimize getting the list of available objects.
Usually, all selections of objects can be systematized somehow. For example, in the case of folders and files, the selections are as follows:
1. List of subfolders of folder A.
2. List of files in folder A sorted by rating.
3. List of files in folder A sorted by creation date.
4. List of files in folder A and all its subfolders sorted by rating.
5. List of files in folder A and all its subfolders sorted by creation date.
Folder access settings change the visibility of entire chunks of such selections. For example, for sample number 1 - for some users, one element may appear or disappear due to a change in the access settings on it.
For selections 2 and 3, the entire contents of the selection may disappear or appear at once.
For selections 4 and 5, that part of the selection that is located directly in the folder with the changed access setting, as well as in its subfolders, may disappear or appear.
So you can cut unique fragments of all samples so that each fragment will contain files with a unique set of access restrictions. Then these fragments need to be stored somewhere. This is a derived sample from the target.
Those. if the target selection is just a selection of all files in a folder in some kind of sorting, and the access layer after the selection should filter only the available ones, then this will not be the case with us, because it is expensive. We will have a list of objects available in advance, available for a certain unique set of prohibitions.
And when a request is made to select available objects, we find out what fragments there are, what access settings they have, which of them are available to our user.
Then we select the contents of all available fragments from the database and, since inside it is a sorted list, we merge them inexpensively.
We can also get such a list with an offset inexpensively. That. we can get not the whole list, because it can be very large, but we can also take it in parts. For example, for pagination.
But this will only work if the folder access settings are not particularly varied. This is usually the case.
In general, everything is usually in this vein.