Login redirects use wrong URL when application doesn't live on web server root

[david.reitter@…]

My application (running on 1.5rc1) sees a request whose view is decorated with @permission_required('admin') redirected to a wrong login URL.

The WSGI application (on Apache2) is mounted in a subdirectory such as www.example.com/foo/...

The redirect to the login page, given a request to www.example.com/foo/exp/manage/ then goes to:

www.example.com/accounts/login/?next=/foo/exp/manage/

rather than

www.example.com/foo/accounts/login/?next=/foo/exp/manage/

LOGIN_URL is not set in my settings.py, as it wouldn't be portable without further ado.

[anonymous]

For what it's worth, user_passes_test in contrib.auth.decorators has "/accounts/login/" as resolved_login_url.
login_url is None. settings.LOGIN_URL=/accounts/login/, which is the default.

Is hard-coding LOGIN_URL, LOGOUT_URL and LOGIN_REDIRECT_URL in conf/global_settings.py the best one can do?

I tried setting FORCE_SCRIPT_NAME in settings.py. os.environSCRIPT_NAME does not seem to exist (Apache/2.2.15 Unix).
I also don't see how these variables will be taken into account when figuring resolved_login_url. So this might be a hard bug.

[Carl Meyer]

Thanks for the report! In Django 1.5 hardcoding is no longer the best one can do; these *_URL settings now accept reversable url names or view function names (see e.g. ​https://docs.djangoproject.com/en/dev/ref/settings/#login-redirect-url), which should be portable and return correct results (presuming url-reversing generally works in your deployment scenario).