I'm designing the authorization of a DRF application. I need to use roles, not just permissions.
I have a model (e.g. project
) in which I have some information (e.g. name, description) that can be modified by some roles (e.g. admin
). But at the same time there are other roles (e.g. worker
) that should not be able to modify that information inside that model but can still modify some other information (e.g. initial and final dates).
I've thought two solutions for this issue. The first one is reading the HTTP request sent and defining the actions to be taken depending on what the request is. This means that each time that a new field is added to the model, I will have to modify this logic. This sounds awfully hard to maintain, is error prone and can introduce vulnerabilities.
On the other hand, I've thought that I could divide the model into two different models. One of them containing the data that just one role (admin
) can modify and the other defining the other data that can be modified by both roles (admin
, worker
). This way, I will not have to parse the HTTP request, because if I get a POST/PUT request affecting the first model and the user has a worker role I can directly reject it.
This situation happens with more than one model.
I would like to know if there's a default way to go or if I'm reinventing the wheel. I think that this situation must be really common. For example, I can think of a git project in which some users have access to do one thing inside a project but not others.
Complementary notes (feedback will be really appreciated):
I most probably will use the django-role-permissions module to implement roles and permissions. I cannot use django built-in groups because, although you can add permissions to them, I will use them to group users (without having anything to do with roles).
I will create a relation between roles and permissions (string based permission, such as
create_project
,modify_project_description
) in a permissions file.When receiving each request I will check which roles have privileges to perform that action and check if the user is any of those roles (activity based authorization, what means that in the endpoint I'll check the activity/action instead of the role).