Other than auth_user, I have never used auth_group, auth_group_permissions, auth_permission, auth_user_user_permissions, and auth_user_user_permissions. What are the specific uses for each of these models? Is it common that one would not need any of these? If so, what would be the best way to get rid of them (doing a straight DROP TABLE or at the django-level)? Would there ever be a downside of removing these?
I'd recommend reading the User authentication section in the Django documentation. It describes the components of the auth system as:
Users
Permissions: Binary (yes/no) flags designating whether a user may perform a certain task.
Groups: A generic way of applying labels and permissions to more than one user.
The simplest use of permissions is to control the actions a certain user can take in the Django Admin site. You can also use permissions to restrict access to your own views using the django.contrib.auth.decorators.permission_required decorator.
When this is combined with groups you can easily assign the same permissions to a whole group of users.
The other database tables you mention (auth_group_permissions, etc.) store the relationships between users and permissions or groups and permissions.
While you may not be using these parts of the authentication system directly you are almost certainly using other code from django.contrib.auth that relies on them. If you're using an app you didn't write (whether it's part of Django or not) then it's probably a bad idea to drop the database tables that app creates.
Related
So I have a requirement where I have to maintain two types of users.
A company and all of its users, to manage day-to-day work. And also create public data like showing a few items and related images and set availability for meetings and more.
Public user who can see the items, images. and can book the meetings.
Now for the first case, every user is created by official email and password as registeruser endpoint from rest-framework. there is user profile and other company data.
For the second type of user (public), I have to give access for social login as well as login by email/mobile (maybe).
I am confused as how to configure this in the best possible way. the company datas' are important.
Should I create both user types in the same database (differentiating by user types)? or should I use a seprerate database then how to fetch data from two databases (never done this)? Also to keep my datas safe from unauthorized access.
Or is there a better way to manage all of my requirements which I'm totally unaware of? Like a better approach.
Looking for an explanation from an experienced person.
Thanks
Maybe what you want is creating a custom User model (or even keep the default one) and implement permissions on views/ressource. This can be implemented by groups, for instance, the public group, in which everyone is (can be public or even no groups) and the private group.
Once you can differentiate between your users, you can add a reference to a ressource and its subressource to the group (ForeignKey on the group) and filters necessary queryset laters on your view. On certain view, you can also restrict some endpoints, through permissions.
Another way would be to use Object Permissions.
Anyway here are the ressources :
https://www.django-rest-framework.org/api-guide/permissions/ (and django-guardian for object-level permission)
and
https://docs.djangoproject.com/en/4.0/topics/auth/default/#permissions-and-authorization
Also, you can take a look on how it is implemented on a opensource project like Sentry: https://github.com/getsentry/sentry/blob/master/src/sentry/api/endpoints/api_applications.py
I want to build the admin site in a way such that, users in a certain group will be able to perform CRUD operations - to records related to their group only.
Is there a way this can be accomplished?
You can easily use the Django Permissions and Group to create this. As the documentation states:
When django.contrib.auth is listed in your INSTALLED_APPS setting, it will ensure that four default permissions – add, change, delete, and view – are created for each Django model defined in one of your installed applications. Read here
You can then easily create Groups with certain permissions such as assigning only read permission to certain group and R/W to another in the Django Admin. If you need more finer record level access certain third party apps will help you such as Django Guardian or Django role permissions
I am new to django. I want to edit default user auth_permissions. More precisely I want to add an integer field in addition to "label", "code" features to distinct permission types (like strong, moderate and etc.). So far I could not find anything like this. I tried to make custom permissions, but could not add them to the permission database. Anyone could help me?
Per Object permission
When i first got into django i also tried relying on the permissions framework within django, I also found the permissions were too broad and inefficient, which lead me to researching django-guardian, I tried to submit an edit to the Django project itself to make more object-base permissions with no success, they said as per object permissions were too personalised for the framework.
The thing is, after getting to work in the industry i realised how people do these permissions in the industry (which honestly was something that bugged me), they mainly create custom login middlewares to keep track of authentication types and add the checks on the view itself. So basically you will have to check in the view who the user is and if you want to give them permission to whatever.
When in MIT they kept asking me to make some weird permissions and I created a table called ExtraordinaryPermissions, this had a ForeignKey to the user and could be used to check within the views what objects the user had access to
It is troublesome, but as-per-object permissions are handed this way in the industry
good luck
How to implement multiple authentication with one model named User? There are different roles attached to this model. I need to implement multiple authentication as user and administrator.
Better not to call it “multi authentication”. Multi authentication is a completely different conecpt. Basically you will have to have 2 guards setup.
But if you are using one single guard (user guard in this case) you will have to simply assign roles by creating a new column in users model called “roles” or what ever you prefer.
After you have setup the roles colum in your users model, create a middleware and configure the rest. Explanation:
In your “role” middleware or whatever you prefer, specify what roles are which and who has access to where. And include that middleware inside your controller in use.
If you stil want to have a multi authentication like one login and redirect separately for users and administrators, I’d suggest you to look at “the dev marketer” multi auth tutorial. It is a well explained and all the source code can be found in whole on github.
Keep in mind that the laravels default /login route is meant for normal user login (atleast for me). You can create a /admin/login route with the above mentioned tutorial.
Hope this helps. Good luck :)
As far as I know, there are 3 permission levels available to use in django (whether by django itself or by using 3rd party apps).
1) Model-based permission
2) Object based permission
3) Row-based permission
It would be great if you tell me the exact differences between these 3 levels of permission system.
Not sure where you got that info, but it's not even remotely correct. Django technically doesn't have any permission system. The auth contrib app adds a system of "permissions" but it's optional and could be replaced entirely with something else. The admin app (also a contrib package, and optional) uses auth, so if you're talking about the Django admin, or using the auth package with your own app(s), then we can talk.
In auth, you have Users, Groups and Permissions. Users come in either "superuser" or "regular" user flavors, and every model in your project gets three Permissions automatically when you run syncdb (with auth included in INSTALLED_APPS): can_add, can_change, and can_delete. Users marked as "superusers" (is_superuser == True), can take any action on any model. Other users need to have Permissions explicitly assigned to them. Further, Groups may have Permissions assigned to them, and then, any User assigned to that Group inherits those permissions.
So, a user could have no ability to do anything with any model, some combination of add, change or delete capability with some or all models or complete access to do anything with any model. There's no concept of "object-based" permissions, in the sense of an "instance". You can either either edit every instance of an model or none. There's also no concept of "row-based" permission. A row in the database table is merely an instance of the model, anyways.