A bit of an odd question-- What practices have other packages adopted? For example, I was playing with ASP.NET last weekend to help out a friend and found their decoupling of authentication from the database to be rather pleasant. Is it possible to add a layer of indirection. In some sense, I want to know: 1) What is the identify of this "putative" user 2) If their Identity is verified, what resources are they Authorized access to.
To determine identity, in the current era, there are many ways--for example: single factor: 1) username/password 2) email address/password multifactor: 1) username/password + PIV card 2) username/password + RSA token Depending on the credential, it can be checked in multiple ways: active directory database etc. To facilitate these different cases, can we have a pluggable "Authentication Service" where the user provides a "credential" which then returns a result of whether the credential is valid or not? We could then implement a few "standard" authentication plugins, such as username/password, email address/password. Third party apps would run against the authentication service, so they shouldn't depend on a particular implementation of user in the database. For legacy users, the current username/password could be implemented and run as the default , so they only have to migrate if they want to...The settings file could be used to register authentication "providers" (for example EmailAuth or UsernameAuth) with the authentication service. If there are multiple authentication methods (users can sign in via openauth or email address for example), then they would fallover in the order they are registered with the authentication service (using settings.py might require some effort to preserve order and avoid multiple registrations...). Is this workable, or would it have too much complexity and too much of a performance hit? Sorry to be so vague...One issue that would come to mind with such an approach is how to deal with things like password recovery in such a scheme using DRY principles... Best, William On Tue, Mar 20, 2012 at 2:02 PM, Donald Stufft <donald.stu...@gmail.com>wrote: > On Tuesday, March 20, 2012 at 2:00 PM, Tom Evans wrote: > > On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft <donald.stu...@gmail.com> > wrote: > > What Alex said. If it was _just_ the username then you'd have a good > argument for > a setting like that. However there's username, email, some people want to > add > fields, some want to get rid of, or combine fields. Ideally any change > would > work > for as many of those use cases without turning into a giant set of boolean > flags > that drastically alter the DB schema. > > > No-one is talking about a 'giant set of boolean flags', or drastically > altering the DB schema. > > The email field needs to accept email addresses of up to 254 octets. > The username field should be able to hold common fields used as a > username, eg emails, and hence needs to be longer. > > That is one boolean flag. No more. If you want more flexibility on the > model, you would use the proposed pluggable auth models. > > What the much maligned setting gives us is a way to provision new > sites and migrate existing sites that care about that situation in to > a position where users with long email addresses can sign up to a > django site. Score. > > Cheers > > Tom > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > So you fix the problem for the people who agree that username should be > longer, and that email > should be longer, but not the people who feel that email should be longer > but username is fine? > > Those settings do not feel any cleaner to me personally than monkey > patching the models. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
