django.contrib.auth.views.password_change is tied to the URL /accounts/login/
|Reported by:||Owned by:||Adrian Holovaty|
|Cc:||treborhudson@…, john@…||Triage Stage:||Design decision needed|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
There's a problem when trying to set up your login/auth URLs different than Django's defaults. The one I've been unable to work around without copying/pasting all of the function is django.contrib.auth.views.password_change.
Here's the gist of the problem...
- password_change is decorated with Django's default login_required decorator.
- The default login_required decorator uses the (un-overridable) LOGIN_URL variable.
- The LOGIN_URL variable is set to "/accounts/login/".
I see 2 fixes...
1) Move LOGIN_URL to global_settings.py
This would allow the default Django login_required decorator to be easily overridden, making things much easier across the board. (Anything decorated with login_required is fixed, the shortcut methods like "redirect_to_login" and "logout_then_login" are fixed.
And there's already variables for the contrib.comments system in global_settings.py so there's already precedent for having contrib apps with stuff in global_settings.py. :)
2) Provide an un-decorated password_change method
Having a password_change method that isn't decorated allows me to decorate it with my own login_required decorator, which redirects to my own login URL if not authenticated.
Either of these should be possible without breaking backwards compatibility.
I have a patch for either. Should I submit both patches? Or should I wait for a design decision and submit the patch for what's decided (if either of the above)?
Change History (5)
comment:1 Changed 10 years ago by
|Patch needs improvement:||unset|
comment:2 Changed 10 years ago by
|Triage Stage:||Unreviewed → Design decision needed|