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
Related
Is it appropriate to use the Django auth model groups for something other than permission management? I am just learning Django, and am trying to make a site that manages groups of users. As an example, think of a site for managing email groups or local community charities or fan clubs or some such. I want to use the groups for managing things like sending an email to everyone in the group, or organizing an event and dividing the preparations between the group or any number of other things that are not permission related. Is this an appropriate use of the auth model, or am I doing this wrong?
If you're not going to use your groups to handle permissions, you'd better create a separate model, just because you'll hardly benefit of using the stock model (which is just a permissions container). And customization is much, much easier when you have a separate model. You could start with just:
class EmailGroup(models.Model):
name = models.CharField(max_length=100)
users = models.ManyToManyField(settings.AUTH_USER_MODEL, related_name='email_groups')
and extend it to your needs.
But there's nothing wrong in using contrib.auth models in a different way. Django is a framework, not a CMS, so you're free to use it as you want.
I'm a bit unsure what to use Django user groups for.
I have an application where every user belongs to a different organisation. The organisations don't have anything to do with read/write permissions. It's just a way to separate groups of users. Every organisation needs some additional fields, like a name, URL, and email address. New organisations will be added to the system over time.
Within every organisation, users can have different permissions for moderation and administration, for which I (also) want to use user groups.
My question: Should I use Django's user groups to define the organisations, or should I just make an 'Organisation' model with a relation to the user?
Nope. User groups are made for different reasons. You CAN use them to define organisations but I think you should think bit further ahead:
will the organisation require more fields than just name?
perhaps you will need permissions in the future to define users roles within organisations?
I'm sure you can come up with more things to think of. But if you answered yes to one of those questions then just create your Organisation model.
1) You need to add group from django admin side under group table.
2) And while creating new user, assign specific group to user using user_obj.groups.add(group_id). Or Let user select group at frontend.
and then user_obj.save()
in Group table, you can create organization
OR
You can create individual organization table and assign assign user to specific organization.
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.
I'm currently developing a Django site in which users can have multiple 'accounts', so that they can seamlessly switch between different public profiles when interacting through the site. What I'm designing is likely to attract multiple registrations per person (and won't be discouraged), I just would like to offer this in such a way as that users can keep the profiles tied together, switch easily and only have to log in once.
The two approaches I've thought up so far include:
One (User model + SiteProfile model) pair and many PublicProfile models per person. AUTH_PROFILE_MODULE is set to point to the SiteProfile model. Issue with this is that I can't easily use per-object permissions: these will be set on the User object and not the public profile, thus permissions to see a page for "PublicProfileA" will also be applied to when the user is masquerading as "PublicProfileB".
One Account model and many (User model + UserProfile model) pairs per person. AUTH_PROFILE_MODULE is set to point to the UserProfile model. This would have the added benefit of the permissions working as intended, and that I can simply have a Custom Backend that will switch users by authenticating a user by if they are currently logged in as another user that has the same Account object as the Foreign Key. Authentication would happen by reading fields on the Account object though, which would mean the password field on every User object would be wasted.
As above, but subclassing Account from User. I've been advised strongly against this though (for reasons unclear).
Is there any pitfalls or better approaches to this? Ultimately, should I use the built-in User model as the one-per-person model that identifies a group of public facing profiles (of which these profiles have a FK back to the User object), or use it as the profile itself, linking back to a single Account object for each person?
Yes, I think the best approach would be to have one and only one User per person and several PublicProfile objects that they can "switch" between. This gives the benefit of only one username/password for them and seems to make the most sense with how Django's auth typically works.
I have recently being trying to create a project which has several levels of user involved.
(Just an example of an abbreviated and rough schema)
ME (Super User)
Client(s)
Customer(s)
Survey Collections
SurveyUser(s)
Invitee(s)
Surveys
Invitee(s) (invitee is a child of both survey and user)
Questions
Etc
I would ideally have:
www.example.com/client/ go to a client interface which you had to be a client to access
www.example.com/customer/ go to a customer interface which you had to be a customer to access
I have already established that using a customised Django admin interface for all of them is probably not going to be possible (or is it?). I am therefore leaning towards manually creating 'admin' interfaces for each level of user, allowing them to manage their respective roles. What is the best way of having different user types and separate interfaces for each one?
I like the way of inheriting users outlined at:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/
But am unsure how I would set up different 'admin' areas for different users.
As a side issue that is related, I am also unsure of how to access the custom properties alongside standard user properties and how to edit/save them in the ACTUAL admin interface that I will use.
I would need to authenticate 'Client' users against a client database to check they are clients but somehow also authenticate against the user database which manages authentication, username, password etc.
I am switching from PHP to Python/Django so any advice greatly appreciated to help me along.
Thanks!
The closest I got to this was based on another stackoverflow article here: How to have 2 different admin sites in a Django project?
I ended up creating two entirely separate instances of django.contrib.admin.sites.AdminSite which seemed to work in the end, albeit not ideal.