How can I extend Auth to allow for multiple users with the same username. In SAAS this is a need because two accounts might have a user called "owner" or something like that.
You could probably subclass the User model and write a custom authentication backend for your new model.
But first I would ask myself "do I REALLY need this?". Having multiple users with the same username sounds like a mess.
The problem with "user names" is that on a site with any decent size population Spencer's Lament (Henry Spencer # U Toronto, Dept. of Zoology) comes into play: all of the good ones are taken. (He was referring to host names in the pre-DNS days, but it still applies.) The only "name" that is pretty much guaranteed to be unique is ... the email address. If you use that as Django's login identifier, then you can allow the user.username to be non-unique and used as a screen name. You still have to allow for people to change their email addresses, but they should still be unique across all users of a site.
We had to do this for a long-established site, as mentioned in this thread.
You can't. Prefix the user name with the account name instead.
Related
Apologies since this might not be the best way to word the question nor is this a coding question per say. I get the general process of creating a staff user within Django.
What I would like to know is if companies send email links that allow their workers to sign up a form to be a staff user or if the employer provides their details and someone on the backend creates this account for them, or some other process I am unaware of?
Well, most of the time they create you account with documents/personal info you've provided to the organization. In my university user accounts are created by staff(no need to fill forms and besides, you can fake that information). At the end, we just go to the website and login with provided credentials, we can add extra info/change password etc. in our account settings.
In conclusion, I would say, it depends.
I set django default user authentication to use an email address instead of a user name.
My worry is about the possible future effects. If the user changes his email will the primary keys need to be changed as I assume the primary key for a user is now an email. What are the basic consequences of this.
The users will also have their own space on the website, hence the urls will need to have some kind of username/unique identification ,I do not foresee an issue here as but if you do please advise.
My main concern being updates of email causing bugs in the database and application.
I know the topic is broad but what would the consequence be here or are there none.
Thank you.
The username is unique, but it is not the primary key. Django creates a primary key id by default. See the docs on automatic primary key fields for more information.
So you should be able to change your username or email without causing problems with primary keys.
However, if you include the username or email address in the url, then these would of course change if the user changes their details.
I mean using the default django authentication backend and functions.
If two users have the same usernames but different passwords is django able to login that user and return the correct User object? Or is the authenticate function not able to handle that scenario? I looked in the github and I don't think the username field in the User model has to be unique
Short answer: no.
Long answer:
Django doesn't support having more than one user with the same username because, even with what you are proposing (password differentiation) there is still a chance two users will have the same password.
Even if it weren't like this, I find it very hard to find a reason to let users share their usernames. You can create an "alias" or something additional, and let it be "not unique"
So I want to keep track of about 100 employees but only five of them should be able to log in into the backend (the rest starts with no loginpossibilities at all) what's the best way to solve that problem ?
I thought of an EmployeeModel that has a 1to1-relation to an abstractBaseUser but is that the way to go or is there something easier ?
~Max
Why not make use of Django 1.5's new customisable User model and model each employee as a user with an extended profile:
In Django 1.5, you can now use your own model as the store for user-related data. If your project needs a username with more than 30 characters, or if you want to store user’s names in a format other than first name/last name, or you want to put custom profile information onto your User object, you can now do so.
By making each employee a "user", you have the balance of being able to control their ability to login (using is_staff) as well as being able to add as much employee profile information that you need.
Why not just have FK from employee to user if an employee has an attached account?
Don't go for over customisation as this can be easily achieved easily using the built-in tools. Make the login_page require a permission suppose say "can login". And just make these 5 users have those permission. So rest will automatically get a permission denied response when trying to login.
I'd like to extend/subclass admin Groups & Users classes in Django.
CourseAdmin group should be doing what admin can do, and they have extra information like email, phone, address.
CourseAdmin should be able to create CourseAdmins, Teachers, Courses and Students.
Teacher should be able to edit courses and students belong to them. They can't create anything new.
I want to make use of current Django admin classes Group & User instead of doing my own. Please kindly advise. Thank you!
Do you mean that the whole group CourseAdmin has one email, phone and address? I doubt that.
Otherwise you don't have to subclass anything. Just create a user profile model (that includes e.g. email, phone, address), create the groups: CourseAdmin, Teacher, Students and set up the permissions accordingly.
You can distinguish the users by checking in which group they are in.
More about user authentication.
You can't both extend and use the existing ones. Use a OneToOneField instead.