id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
3372	django.contrib.auth.views.password_change is tied to the URL /accounts/login/	Rob Hudson <treborhudson@…>	Adrian Holovaty	"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...

 1. password_change is decorated with Django's default login_required decorator.
 2. The default login_required decorator uses the (un-overridable) LOGIN_URL variable.
 3. 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)?"		closed	Contrib apps	dev		fixed	login	treborhudson@… john@…	Design decision needed	0	0	0	0	0	0