contrib.auth.handlers.modwsgi fails for some backends

[Andre Bell]

In contrib.auth.handlers.modwsgi authentication is implemented with a check_password function, which in turn is based on "user.check_password". However, this forces a check of the given password against the password stored in the database.

For some backends like, e.g. django_auth_ldap, no usable password is stored in the database. Thus, this check will fail.

Therefore the function should be implemented using a call to "authenticate", which will correctly verify the given password against the different authentication backends.

[Baptiste Mispelon]

One issue (and probably the reason why check_password is implemented that way) is that, according to the mod_wsgi documentation [1], the handler function should return None, True, or False depending on whether the user exists in the database and whether the provided password is correct or not (respectively).

With authenticate, we either get a user object or None which means we can't distinguish between a non-existing user and a bad password.

I'm not sure how much of a problem it'd be to return None instead of False in case of an invalid password but it might break backwards-compatibility so we should tread carefully.

[1] ​http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms#Apache_Authentication_Provider

[Graham Dumpleton]

Returning None allows Apache to try a different authentication provider if more than one was setup in Apache. The question is whether when using Django for authentication that people would even want to do that or whether one views Django as the only authoritative source.

[Andre Bell]

How about using authenticate to try all django authentication provider (backends) and if authenticate fails use check_password.
In that case failed authentications will still allow apache's other auth provider.