Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#849 closed defect (fixed)

login_required redirects to pages without parameters and so loses them

Reported by: hugo Owned by: adrian
Component: Core (Other) Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by hugo)

This would allow accessing GET, POST or META stuff in the templates without the view function taking care of it. For example if using a login_required decorator, you could just put a <input type="hidden" name="next" value="{{ request.path }}" /> into the login.html template and have it automatically redirect to the secured form. Currently you need to pass the 'next' parameter to the form itself and use that to build the next field. And it's currently impossible to pass on request parameters to the logged in page.

Change History (8)

comment:1 Changed 10 years ago by hugo

  • Description modified (diff)

comment:2 Changed 10 years ago by hugo

  • priority changed from normal to high
  • Type changed from enhancement to defect

An alternative - at least for my specific problem of redirecting from login to a page with parameters - would be to enhance the user_passes_test decorator to not only pass on request.path, but additionaly pass on parameters. But for that the HTTPRequest subclasses need to store the query string (environQUERY_STRING? in wsgi.py and _req.args in modpython.py) somewhere you can access directly without knowing what handler is used.

Since this actually breaks login_required for GET-parameterized pages, I change it from enhancement to defect and up the priority - this will most surely byte newbies when they have parameterized pages (like for example bookmarklets often are).

comment:3 Changed 10 years ago by adrian

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

I'm marking this as a wontfix, because we want to encourage developers to put logic in the views, not in templates.

Feel free to write your own Context subclass that puts the request in the template context.

comment:4 Changed 10 years ago by hugo

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from DjangoContext should fill in the request itself into the context to login_required redirects to pages without parameters and so loses them

Ok, agreed, if you don't want the request in the Context - but then you need to fix the problem with parameterized pages using login_required, that's why I open this again. Because currently if you have a parameterized page that uses login_required, the login will redirect back to the original page _without_ the parameters. And that's most definitely irritating. I'm changing the title to reflect that fact.

comment:5 Changed 9 years ago by feiyu.xie@…

Hi there! Will this be fixed at all? It's pretty useful (at least to our project) to be able to preserve the parameters. Could it be a simple change to django/views/decorators/auth.py line 13 from "request.path" to "request.get_full_path()" (might need some encoding/escape, etc)?

comment:6 Changed 9 years ago by anonymous

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:7 Changed 9 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 Changed 9 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

Fixed in [2954].

Note: See TracTickets for help on using tickets.
Back to Top