On Wed, Jan 10, 2007 at 01:10:03PM -0600, Joseph Kocherhans wrote: > > 1. Named auth backends > > Right now, user logins are coupled to the actual location of an auth > backend. The python dotted path of the backend is stored in the user's > session when they login. If you were to move the backend to a > different module, any user who was logged in via that backend would > get a 500 the next time they tried to view a page because the class > corresponding to the dotted path in their session would no longer > exist. I propose to register and lookup backends by name to fix this > problem. Here's a configuration sample: > > # a tuple of (name, path) tuples > AUTHENTICATION_BACKENDS = ( > ('default', 'django.contrib.auth.backends.ModelBackend'), > ('ldap', 'mypkg.backends.LDAPBackend'), > ) > > This will allow you to change to a different backend class, or move it > to a different module or package without breaking your existing logins > since they will be looked up by name rather than by path.
This is a problem I've run into myself, when I switched from having my LDAP backend in my app, to running it as a patch (#2507). Currently I'm assigning the new backend the old one's name so old session cookies still work. In other words, +1 on this. > > 2. Link users to their backends > > Adding a 'backend_name' field to django.contrib.auth.models.User would > allow us to tie a user object to a specific backend when it is > created. This would be a choice field with the choices populated from > AUTHENTICATION_BACKENDS. It would allow us to use default django users > and look them up by the type of backend they are tied to. (i.e. give > me all OpenID users, give me all ldap users, etc.) This depends on > point one, and makes the next proposal possible. > +1. The LDAPBackend in trac currently makes a User object when a user first authenticates, and provides a random default password. This is so if someone tries to authenticate and fails and the next backend is the Model backend, the person can't login with a static default password. It would be nice to not have to worry about that. > > 3. Store backend specific user profiles > > I also propose to extend the AUTH_PROFILE_MODULES pattern to support > backend specific profiles. This would depend on both of the previous > points. Here's a configuration example: > > BACKEND_PROFILE_MODULES = { > 'ldap': 'mypkg.models.LDAPProfile', > } > > And to get the backend specific profile for a user: > > user.get_backend_profile() > > get_backend_profile() would user user.backend_name and > BACKEND_PROFILE_MODULES to return the appropriate profile model. > +1 > > 4. Dealing with username > > Things like OpenID don't require a username, but the default > django.contrib.auth User model does. We could hack something together > in an OpenID backend to make up a unique username, but that seems kind > of silly since we just don't need it. To fix this, the required=True > attribute of the username field should be removed and a custom > validator should take it's place. This validator should look at the > new user.backend_name field to determine if the *backend* requires a > username field. If backend_name is not available in the validators > all_data argument, the validator will assume that username is > required. My initial thinking is that an attribute named > username_required or something similar could be checked on the backend > object. To indicate that username is *not* required, you'd just set > that attribute on your backend class. For instance: > > class OpenIDBackend(object): > username_required = False > > def authenticate(request=None): > # validate the openid server response and return a user > +1 -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601
pgpMe4PdWopg4.pgp
Description: PGP signature