Opened 2 years ago

Last modified 2 years ago

#20589 new Bug

contrib.auth.handlers.modwsgi fails for some backends

Reported by: graham4django Owned by: nobody
Component: contrib.auth Version: 1.5
Severity: Normal Keywords: handlers, modwsgi
Cc: bmispelon@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (4)

comment:1 Changed 2 years ago by claudep

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 2 years ago by bmispelon

  • Cc bmispelon@… added

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

comment:3 Changed 2 years ago by grahamd

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.

comment:4 Changed 2 years ago by graham4django

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.

Note: See TracTickets for help on using tickets.
Back to Top