Re: Authentication when usernames are not unique

Wow, nice. You are probably right in not inheriting from PermissionMixin and AbstractBaseUser and just re-implementing the needed functionality. I ended up doing the same thing for my custom user and auth backend as well. Not as convenient, but hey, it works right? ;-) Bravo. -James On Jan 20,

Re: Authentication when usernames are not unique

Ok, here's a stripped-down solution. I ended up creating a new SchoolUser user model with a OneToOne relation to my LegacyUser, to keep the LegacyUser model uncluttered. The SchoolUser implements all methods from AbstractBaseUser and PermissionsMixin but doesn't inherit from them, because I

Re: Authentication when usernames are not unique

BTW, I reread you're last note. The references to AbstractBaseUser were meant for inheritance, meaning that your custom user would inherit all of the same properties and not need to redefine the wheel. You can't inherit from AbstractUser though because you are modifying the username field. -James

Re: Authentication when usernames are not unique

"A pallet of authentication systems..." Yep, you work for an educational entity, as do I. :-D You can pursue the LegacyUser model as your custom user model. That would make your LegacyUser objects the 'local' Django users that have been referenced. Not sure about the name though, might indicate

Re: Authentication when usernames are not unique

Hi guys, Thanks for a lot of useful answers! My schools use a palette of authentication systems; regular hashed password check with a hash I have access to, LDAP auth and WAYF (a Danish educational SSO solution using Shibboleth). Those are the least of my worries right now, though. I'll have

Re: Authentication when usernames are not unique

For a pure authentication scenario where permission checks never go beyond user.is_authenticated(), that's probably true. If all the OP is doing is displaying data, they may be able to get away with manually associating the campus and user within the session after, and displaying data based on

Re: Authentication when usernames are not unique

Shibboleth 2.0 lets you setup a discovery service (or portal would perhaps be a better term) letting the user select which ID Provider (IdP) they will authenticate to. All you have to do on the Service Provider (SP) side is specify the discovery URL and what IdPs you allow. Nothing needs to be

Re: Authentication when usernames are not unique

Hmm, yes, Shibboleth will require some extra trickery in multiple views with redirects to the respective campus portal, etc. I've never done it myself, but I believe the API is pretty well documented. -James On Jan 19, 2015 1:48 PM, "James Schneider" wrote: > That's an

Re: Authentication when usernames are not unique

That's an interesting (but understandable) requirement, which means you are probably in for an interesting time. Undoubtedly you'll need to roll your own authentication backend ( https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#authentication-backends) and a custom user that

Re: Authentication when usernames are not unique

Just as a case study, Shibboleth does this by having unscoped and scoped usernames. The scoped username should be globally unique and takes the form of "u...@school1.edu". Unscopped is not globally unique, but unique for a particular scope (ie: "user"). It's temping to say "ahh... email address!"

Authentication when usernames are not unique

Hello I'm creating a Django frontend for a legacy school system. The legacy system has users, but usernames are only unique together with a school: class LegacyUser(models.Model): school = models.ForeignKey(School) username = models.CharField(max_length=40) class Meta: