Code

Opened 6 years ago

Closed 5 years ago

Last modified 3 years ago

#8906 closed (wontfix)

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

Reported by: levity Owned by:
Component: contrib.auth Version: 1.0
Severity: Keywords:
Cc: graham@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:

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 (1)

8906_auth_script_prefix.diff (3.4 KB) - added by lygaret 5 years ago.
really basic patch for script_prefix aware @login_required

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 years ago by lygaret

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to lygaret
  • Patch needs improvement unset
  • Status changed from new to assigned

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

comment:2 Changed 5 years ago by lygaret

  • Has patch set
  • Needs tests set

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

Changed 5 years ago by lygaret

really basic patch for script_prefix aware @login_required

comment:3 Changed 5 years ago by lygaret

  • Owner lygaret deleted
  • Status changed from assigned to new

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

comment:4 follow-up: Changed 5 years ago 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.


comment:5 Changed 5 years ago by grahamu

  • Cc graham@… added

comment:6 in reply to: ↑ 4 Changed 5 years ago 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?

comment:7 Changed 5 years ago by jacob

  • milestone set to 1.1
  • Triage Stage changed from Unreviewed to Accepted

comment:8 Changed 5 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:9 Changed 3 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.