Opened 13 years ago
Closed 12 years ago
#18998 closed Bug (fixed)
Removing an authentication backend that's cached in a user's session causes exception
| Reported by: | Owned by: | jorgebastida | |
|---|---|---|---|
| Component: | contrib.auth | Version: | 1.4 |
| Severity: | Normal | Keywords: | |
| Cc: | sunny@… | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
Here's the scenario:
- I add a new authentication backend to
AUTHENTICATION_BACKENDS. - I deploy the code and a user logs in using that backend, and then logs out.
- I decide I want to change the name of the backend, so I do, and update
AUTHENTICATION_BACKENDSaccordingly. - I deploy the code, and the same user loads the login page again.
On loading the page, an exception will be raised:
Traceback (most recent call last):
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/core/handlers/base.py", line 111, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/console/base.py", line 105, in wrapped
result = func(request, *args, **kwargs)
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/contrib/auth/decorators.py", line 19, in _wrapped_view
if test_func(request.user):
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/utils/functional.py", line 184, in inner
self._setup()
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/utils/functional.py", line 248, in _setup
self._wrapped = self._setupfunc()
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/contrib/auth/middleware.py", line 16, in <lambda>
request.user = SimpleLazyObject(lambda: get_user(request))
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/contrib/auth/middleware.py", line 8, in get_user
request._cached_user = auth.get_user(request)
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/contrib/auth/__init__.py", line 100, in get_user
backend = load_backend(backend_path)
File "/var/www/httpdocs/.env/lib/python2.7/site-packages/django/contrib/auth/__init__.py", line 22, in load_backend
raise ImproperlyConfigured('Module "%s" does not define a "%s" authentication backend' % (module, attr))
ImproperlyConfigured: Module "project.apps.core.backends" does not define a "EmailOrUsernameModelBackend" authentication backend
EmailOrUsernameModelBackend is the name of the old backend that has been renamed.
Change History (12)
comment:1 by , 13 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 13 years ago
I think the code that retrieves the auth backend from the session should ensure it's within AUTHENTICATION_BACKENDS. If it's not, treat it as invalid and ignore it.
comment:3 by , 13 years ago
| Owner: | changed from to |
|---|
comment:4 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Triage Stage: | Accepted → Fixed on a branch |
comment:5 by , 13 years ago
| Has patch: | set |
|---|---|
| Triage Stage: | Fixed on a branch → Accepted |
The ticket isn't fixed until a core developer commits the code to the master. You should have just marked the "Has patch" flag. See https://docs.djangoproject.com/en/1.4/internals/contributing/triaging-tickets/#triage-stages for more info :)
comment:7 by , 13 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
We should probably remove the fixed on branch stage
comment:8 by , 13 years ago
| Status: | reopened → new |
|---|
comment:9 by , 12 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:10 by , 12 years ago
The patch submited by @mhaligowski did not fix this ticket's issue but another that I've just raise (https://code.djangoproject.com/ticket/20438#ticket).
Following @claudep advice in the first comment I've submit a patch capturing ImproperlyConfigured and returning an AnonymousUser instead. Pull request here https://github.com/django/django/pull/1092.
comment:11 by , 12 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:12 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
I guess that catching
ImproperlyConfiguredin addition toKeyErroringet_useris the way to go here.