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
