Code

Opened 3 years ago

Closed 3 years ago

#15537 closed (wontfix)

allow the login_url accept a relative path

Reported by: lanyjie Owned by: nobody
Component: contrib.auth Version: 1.3-beta
Severity: Keywords: relative path login_url
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

In the development version, the login_required decorator accepts a parameter named login_url:

@login_required(login_url='/accounts/login/')
def my_view(request): ...

Sometimes, the login_url may depend on the request path (for example, when the path already implies the login name -- the name may even not be known to the user, and the login page would only ask for a password). Allowing a relative path would be great in this case:

@login_required(login_url='login.html')
def my_view(request): ...

To implement this, simply insert an one-way if-statement into the decorated view function before using login_url:

def login_required(login_url=None, ...):
   ...
   def decorated_view(request, *args, **kwds):
      ...
      if login_url and not login_url.startswith('/'):
         login_url = request.path + login_url
      ...
   return decorated_view

A more general approach is to have login_url accept a callable that takes the request as a parameter and returns an absolute path; however, I don't have a use case for that yet.

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

I'm not sure I agree that the proposed feature would be a good thing. Authentication shouldnt' be tightly coupled to application design, and the design your proposing would require either a tightly coupled design, or a large number of deployed login views. I'm not sure I want to encourage either of those practices.

If you want to argue for this feature, please start a discussion on django-dev; my suggestion to you would be to try and explain why this sort of design is the right thing. i.e., provide a much better explanation of your use case.

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.