Django

Code

Ticket #8906 (closed: wontfix)

Opened 2 years ago

Last modified 1 year ago

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

Reported by: levity Assigned to:
Milestone: 1.1 Component: Authentication
Version: 1.0 Keywords:
Cc: graham@flyingcracker.com Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 1 Patch needs improvement: 0

Description

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.

Attachments

8906_auth_script_prefix.diff (3.4 kB) - added by lygaret on 12/11/08 16:46:35.
really basic patch for script_prefix aware @login_required

Change History

12/11/08 16:37:36 changed by lygaret

  • owner changed from nobody to lygaret.
  • needs_better_patch changed.
  • status changed from new to assigned.
  • needs_tests changed.
  • needs_docs changed.

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

12/11/08 16:46:01 changed by lygaret

  • has_patch set to 1.
  • needs_tests set to 1.

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

12/11/08 16:46:35 changed by lygaret

  • attachment 8906_auth_script_prefix.diff added.

really basic patch for script_prefix aware @login_required

12/11/08 17:07:56 changed by lygaret

  • owner deleted.
  • status changed from assigned to new.

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

(follow-up: ↓ 6 ) 01/15/09 12:35:31 changed by 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.

01/19/09 13:08:14 changed by grahamu

  • cc set to graham@flyingcracker.com.

(in reply to: ↑ 4 ) 01/20/09 10:54:49 changed by 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?

02/25/09 16:31:38 changed by jacob

  • stage changed from Unreviewed to Accepted.
  • milestone set to 1.1.

04/01/09 10:38:05 changed by jacob

  • status changed from new to closed.
  • resolution set to wontfix.

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.

Add/Change #8906 (django.contrib.auth settings.py URL's aren't portable)




Change Properties
Action