I'm working on a rewrite of an app that has three categories of users
and I'm wondering about the best way to link them to the
authentication system:
In-House Staff,
Contractors,
Customers who interact via the app.
The in-house staff model doesn't store any address info. Contractor
and Customer have some common attributes (address, phone number,
email, etc.) but they have completely different relationships to the
rest of the system.
In the current version I have discrete models for each type and I
manually maintain a link to the equivalent of the user profile table.
But I don't have model inheritance available in the current system.
My question is, do you have any general advice for this and how would
you link it to the existing Auth system, or is there a 3rd party auth
system that you'd recommend I look at.
Thanks.
What you could do is make the user profile model polymorphic. So that whenever you create a user you can add one of the user profile "types" check out: https://github.com/specialunderwear/django-polymorphic-easymode
its documented nicely and always worked for me.
Related
I am designing a Django application (v1.6) and need to do several things with users:
Add custom fields, such as a foreign key for user department
Trigger database changes when certain fields change. For example, when the user's department changes I need to move inventory in another model out of the old department and into the new. I was planning to use a pre_save receiver to do this.
Define custom permissions, such as a user can only modify rows in a table that are associated with their department.
Eventually I want to integrate the application with our Active Directory server for authentication.
I looked at the options in the documentation and see that there are several options, from extending the user model with a one-to-one relationship to writing a custom user model.
What design should I use to meet all of the above goals?
Take a look at this blog post: it provides all the design principles to achieve your goals.
http://www.roguelynn.com/words/django-custom-user-models/
I would also take a look here for more information about Configurable User Models, if you want to have your own authentication scheme:
http://procrastinatingdev.com/django/using-configurable-user-models-in-django-1-5/
I also found the following reference helpful: http://www.sofokus.com/blogi/custom-user-model/
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 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'm wondering what people's thoughts are on joining models directly to the auth.User object vs to the user's profile model.
I'm storing some different types of models which my user are adding in my app. App users will search for other users via criteria on these models.
On the one hand, I'm thinking that if I join straight to User then I won't need to do request.user.get_profile() each time I need to grab the User's records, and it doesn't presuppose that a User always has a profile (they do in my app at the mo, but still). This leaves the profile model as just containing the user's contact details.
On the other hand, I imagine I'll most likely need values from the Profile (eg name, location) when I'm looking up these other models.
No doubt either will work, so maybe it doesn't matter, but I just wondered what other people's thoughts were.
Thanks!
Ludo.
I would also recommend creating foreign-keys to the User model. It just makes your life simpler when working with the user object in the view, for one. So, you can do things like request.user.foo_set, etc. without having to go through the profile model.
In general: If you want to make your apps reusable, always create foreign keys to User model.
As you already said, in most cases you will need User as well as Profile instance, so to prevent multiple database queries, use cache.
If reusability isn't relevant, create foreign key to Profile and use select_related() to get User instance with single query.
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.