Hi, I’m struggling to understand how can I use, or not use, the django.contrib.auth. Let me share my scenario:
I have the django allauth for authentication
There is a model Recipe that has an owner field(User)
Only the owner can edit the recipe. ok I can check logged user against the owner
However, the owner can invite another user, like a nutritionist, to edit his recipes. how exactly would the best approach?
I see some solutions that create another field, many to many ‘editors’, and then add the nutritionist. I don’t know why, this looks strange to me.
Is there a way to use the django.contrib.auth for this? Like User, Group, and Permission. All the Nutritionist from this group can edit this Recipe or Nutritionist is a Group, or Nutritionist is a Profile.
Truly, my problem relies on understanding more about the concept of Users, Profiles, and Permissions and how to use all of that together and efficiently like a pro.
I know that this is a deep subject. I appreciate any link to literature about the subject, this is bothering me and I want to master the solution.
One solution for this would be to create a group for each owner. The owner would then be given the ability to add users to their group.
Side note: Materially, this is almost exactly the same as the editors pattern that you describe as looking strange to you. However, it’s not strange.
Beyond that, what you’re actually talking about here is a row-level security model. Yes, the Django auth system can be used as the basis for that. However, it’s not a solution that’s built-in.
For some conversations along those lines, see the threads at:
In Django terms, a Permission is just a name. They are typically used by Django, in views, to determine whether a user is allowed to perform some action. There’s really nothing special about them. They’re not any kind of active component. You could almost think of them as a type of “token” that a user either has or doesn’t have. This “token” doesn’t do anything, but different components can check to see if a user has it.
The best use of a Django Group is to think of them as “roles” in a traditional “role-based” security architecture. On one hand, they’re related to some number of permissions. On the other hand, they’re related to some number of users. So what they really do for you is allow the assignment of multiple permissions to multiple users in a consistent way.
This actually isn’t that deep of a subject. These components aren’t that sophisticated, there’s just not a lot of “there” there. As a result of this, while you can use these to build a row-level security system, there’s a lot that you would need to build yourself. How you do this is going to depend upon your precise requirements. (Or, find a suitable package on djangopackages.org to help.)