django.contrib.auth settings.py URL's aren't portable

[levity]

in r8015, django gained the ability to be moved from one path to another easily by setting "PythonOption django.root /whatever" in the httpd conf, as described at ​BackwardsIncompatibleChanges.

However, the LOGIN_URL, LOGOUT_URL, and LOGIN_REDIRECT_URL variables in settings.py don't seem to be affected by these changes. So, if i have LOGIN_URL = '/login/' in settings.py, it'll still resolve to just "/login/" even if i have django.root set so that everything else becomes "/whatever/some_other_path/". which makes the app non-portable.

[lygaret]

Hey a couple of us here ran into this and coded up a quick

[lygaret]

Er, didn't get the comment finished...

Anyway, we coded up a quick patch, and the built in tests are working. I'm having trouble figuring out how to write a test that will invoke the @login_required decorator though, so if anyone would like to give us a hand that would be great.

The test cases are as follows:

1. Ensure that a view decorated with @login_required redirects to settings.LOGIN_URL when get_script_prefix() is
2. Ensure that, after set_script_prefix('/some/long/path'), @login_required redirects to /some/long/path/ + settings.LOGIN_URL
3. Ensure that, after logging in with no next? parameter, the login form redirects you to settings.LOGIN_REDIRECT_URL when get_script_prefix() is
4. Ensure that, after logging in with no next? parameter, the login form redirects you to /some/long/path + settings.LOGIN_REDIRECT_URL when the script_prefix is set
5. Ensure that, after logging in with a next? parameter, the login form redirects you to the next? parameter with no change to the path, irrespective of script_prefix

[lygaret]

really basic patch for script_prefix aware @login_required

[lygaret]

After being told on IRC that it's not worth pursuing, nevermind then.

[Wayne K. Werner]

I don't know who says this isn't worth pursuing, but I have been bitten by this. It severly hampers the usability of the auth system. I've got a custom login_required decorator going with 'pull this out when the bug is fixed in django' comments.

Since reverse lookups are portable, perhaps the ability to use LOGIN_NAME, etc. in auth would be a good way to quash this? It could be backwards compatible by using a AUTH_USE_NAMED_URLS settings defaulting to 'False', and falling back to the _URL variants.

I would be happy to work on this if this seems to be an acceptable solution, or would appreciate input on alternate paths of attack.

[alee8]

Replying to AmanKow:

I don't know who says this isn't worth pursuing, but I have been bitten by this. It severly hampers the usability of the auth system. I've got a custom login_required decorator going with 'pull this out when the bug is fixed in django' comments.

Since reverse lookups are portable, perhaps the ability to use LOGIN_NAME, etc. in auth would be a good way to quash this? It could be backwards compatible by using a AUTH_USE_NAMED_URLS settings defaulting to 'False', and falling back to the _URL variants.

I would be happy to work on this if this seems to be an acceptable solution, or would appreciate input on alternate paths of attack.

I would like to second this inquiry. I've hit on this while using the django.root feature. Any logins using the login decorator is not being redirected properly with the django.root prefix.

Is the workaround proposed by AmanKow? our only option?

[Jacob]

On review, I'm not sure this is necessary. Settings files aren't intended to be "portable" -- in fact, they're the very definition of single-purpose -- so I can't see why you wouldn't just set LOGIN_URL correctly in your settings file. This change produces indirection for very little gain.

[Jacob]

Milestone 1.1 deleted