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.
+1
A:
You can't. Prefix the user name with the account name instead.
Ignacio Vazquez-Abrams
2010-02-20 23:01:26
Better to know what I can't do so I can work on a solution than go on a wild goose chase. +1
orokusaki
2010-02-21 01:45:45
+2
A:
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.
Ludwik Trammer
2010-02-20 23:08:18
@Ludwik I absolutely do need it. How can I control what username my account holders decide to use? 250 accounts could all be owned by somebody named mark. These usernamed aren't for me and my team.
orokusaki
2010-02-21 01:38:03
@Ludwik thanks for the link. I, for some reason, couldn't find that section yesterday. +1
orokusaki
2010-02-21 01:44:10
+2
A:
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.
Peter Rowell
2010-02-21 03:02:55
+1 for this excellent observation. The problem still exsists however, because a single person could have users on multiple accounts (like in the case of a web designer who works with multiple companies who use the same hosted CMS.
orokusaki
2010-02-21 06:36:14
@orokusaki: Absolutely, but that moves us into a problem of significantly higher complexity -- some combination of SSO (Single Sign On) mashed together with multiple and/or different identities/roles with different levels of access across multiple sites. If you don't actually need to solve that problem, then don't. If you simply *must* solve it, then it needs to be elevated to the number 1 position on your Technical Risks list for this project because it means one of your most important Entities in the entire design is not understood well enough to code, and that means Trouble.
Peter Rowell
2010-02-21 17:54:47
@Peter I'm going to have to create my own entire User and Auth system. Django has very weak support for creating an SAAS, and the answers to people's questions about SAAS in Django on SO make that obvious. I would venture to guess that not many SAAS exist that are written in Django. I might contribute whatever I have to the public on BitBucket afterward (if it's robust enough for general use).
orokusaki
2010-02-21 23:01:18
@orokusaki: It may not be as bad as you fear. In a worst-case situation you go in and directly hack contrib.auth to allow for usernames as you need to define them. The bigger problem comes if you need a full-on ACL (Access Control List) mechanism, but even that isn't too bad. For a recent site I implemented a strange fine-grained access mechanism on a per-user/per-object basis and it was about 2600 lines of code total. Send me email if you would like to bang heads on this. [email protected]
Peter Rowell
2010-02-22 00:25:00