Opened 8 months ago
Closed 8 months ago
#35288 closed New feature (wontfix)
login_required / user_passes_test redirects back to POST-only view
Reported by: | Patrick Rauscher | Owned by: | nobody |
---|---|---|---|
Component: | contrib.auth | Version: | 5.0 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Assume an application with session timeout and a login restricted area. In this area there is a form, POSTing its content to a view which has @require_http_methods(["POST"])
as a security percaution.
A valid user visits the site with the form, stays there long enough for the session to time out and submits the form. Django will check if the user is logged in, which leads to user_passes_test
evaluating to false and redirecting the user back to login while setting the next-url-parameter to the submit-view. After login, the user is redirected to the view which returns error 405 due to @require_http_methods(["POST"])
.
I'm quite sure this is a bug, as 405 would not be the error he anticipates, but I'm not too sure about a possible fix. One solution would be to check in user_passes_test
if we have a POST/PUT/...-Request and try to use Referer in that case?
Change History (1)
comment:1 by , 8 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Type: | Bug → New feature |
Hello Patrick, thanks for your report and for helping making Django better.
I do understand your issue though it seems a bit of a niche problem to me. I believe you could fix this by providing a custom view for the
login_url
param of theuser_passes_test
method that would redirect the user to whatever view is more appropriate than the POST-only view, particularly a view that could handle GET requests and provide a way of refreshing the session and taking the user to a suitable page to redo the POST. Also, your POST-only view could be tweaked so GET requests are allowed only when coming from a login operation, and the view itself could raise 405 for every other situation.In summary, I don't think this is a bug in Django, and I don't think the outlined issue applies to the broader ecosystem. Django is a framework designed to offer robust and accurate solutions for common scenarios, so I'll close the ticket accordingly, but if you disagree, you can consider starting a new conversation on the Django Forum, where you'll reach a wider audience and likely get extra feedback. More information in the documented guidelines for requesting features.