tickets_full: 3372

This data as json

id created changetime last_pulled_from_trac stage status component type severity version resolution summary description owner reporter keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
3372 2007-01-26 18:55:44 2007-08-25 05:11:46 2019-06-24 00:51:09.841156 Design decision needed closed Contrib apps     master fixed django.contrib.auth.views.password_change is tied to the URL /accounts/login/ 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''' 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 so there's already precedent for having contrib apps with stuff in :) '''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)? adrian Rob Hudson <> login 0 0 0 0 0 0
Powered by Datasette · Query took 3.823ms