Opened 12 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_BACKENDS
accordingly. - 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 , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 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 , 12 years ago
Owner: | changed from | to
---|
comment:4 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Triage Stage: | Accepted → Fixed on a branch |
comment:5 by , 12 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 , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
We should probably remove the fixed on branch stage
comment:8 by , 12 years ago
Status: | reopened → new |
---|
comment:9 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:10 by , 12 years ago
In the same way if a user logs in with backend A and then we remove A from AUTHENTICATION_BACKENDS
the user will still be log in even if the backend is no longer available in AUTHENTICATION_BACKENDS
but the module is.
Will write a patch and send a Pull Request.
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
ImproperlyConfigured
in addition toKeyError
inget_user
is the way to go here.