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.
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
In my wen application i mad different login for different person like for HR ,for engineer ,for owner using django user creation form , and authenticate them using Django authentication ,now everything is work very well i am able to add user from the front add
but the problem is that everyone get same power and authority , i can change it from the admin penal but it will not be beneficial for my client/user I WANT ALLOW DIFFERENT KIND OF PERMISSIONS TO DIFFERENT GROUP OF USER(daynamicaliy with using django penal) show How can i do that.
(i'm beginner so its request to all of you to give answer in some detail format)
THANK YOU
If you refer to the docs here, there is already a default system where you can add or remove permissions to a specific group of users. What you should do next is to create different subclasses for different types of users.
So your models will look something like this eventually:
class User(models.Model):
# just keep whatever you had here
# Engineer and Manager will both be subclasses of User
class Engineer(User):
# add whatever permissions you have
class Manager(User):
# add different permissions
In this way, you will be able to apply custom permissions to different groups of people.
I'd like to add the capability for users to create their own groups and invite others to join the group (or leave the group) or for users to request access to a group to a django app.
The group in this case is basically a pool of potential players for a football match, from which the actual players will be chosen.
Is the standard django auth groups system the correct thing to use here or is there another way? I'd need it to be able to do invitations and stuff, obviously.
I can obviously write my own but is there another app out there that already does this kind of thing nicely?
If not, has anyone got any tips on how to go about this?
Creating your own model will give you more control to add extra information to those groups, such as the invitation system you described. The auth groups models was designed for classifying users by what level of control they have over the data on the website, which isn't what you want a groups model for. A new model will be much easier for you work with than trying to extend the existing groups model; which has built in functionality that you won't use, and probably has security features that will make it difficult to work with.
I have developed an app for school management. Teachers and others roles have an account (django user) to control student attendance, Behaviors issues, etc.
Student is a model itself. Teacher is a User proxy.
At this moment I'm ready to extend the app to allow parents access to children information (is cruel, but for the sake of students ;)
I'm evaluating this alternatives:
Make a simple php app only for parent access (with dedicated db user
and views). It seems secure but I don't like php.
Add a password field to Student model and build my owner authentication system. I
don't like to have a 'django authenticated student'.
Integrating Student authentication with actual auth schema. I don't like this for
security reason, this means to check all views security, and this mix teachers and students.
Create a new django application only for students (and parents) with two databases, the 'school' database and a new one with auth for students
What is for you the best way to authenticate parents before to see children information?
Any suggestions are wellcome. Thanks a lot.
Ah! I think that is easy that parents forgot passwords.
School has over 800 students, app store more than 1milion of presence cheks for year, lot of Parents interviews, ...
Django contrib.auth models incorporate groups and permissions in addition to user accounts. In fact regular django users and django admin users share the same model only with different permissions.
Considering, the default authentication model (from a security standpoint) is already shared with much bigger consequences in case of a breach, I don't see a reason why you shouldn't have students authenticate with the same model and just assign them into a separate group and manage their permissions. Your security will not be worse or better from what it already is.
As far as development side goes, all you have to do is simply use decorators on the view handlers which are Teachers/Parents only to limit student access to them.
See: Permissions decorator
If for whatever reason this is unacceptible (although I cannot surmise a reason from what you said), you will have to do either:
Write your own middleware that injects itself into contrib.auth (reinvent the wheel)
Use an external system to verify permissions (completely orthogonal to Django's approach and will actually complicate your system much more than to use integrated contrib.auth)
Additional down side to doing your own authentication system is that you now have to worry about all kind of security issues that Django solves for you (like CSRF protection, SQL injection/escaping and many others). Not to mention bugs that can creep in vs. using tested and proven code/model provided by contrib.auth.
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.