/oscar/checkout/thank-you/` returns 404 when checkout_order_id not in session
See original GitHub issueIssue Summary
Oscar 2.0 smoke tests, GET /oscar/checkout/thank-you/
returns 404.
The smoke test is obviously requesting this without going through the checkout process, so 403 could be appropriate. It is a very long stretch of the meaning of 404 to use it here - the resource was found - it was the resource is responding that it doesnt like the request context.
ThankYouView
has raise http.Http404(_("No order found"))
More interesting, it only does this if a session field checkout_order_id
wasnt found, which that error message does not convey accurately.
If it is about a missing field, it could be a SuspiciousOperation
.
However as it is a GET, that page URL could be in a users browser history, in which case it could be inadvertently loaded in a new session, which isnt really suspicious, and the user shouldnt see a http error page.
It should be possible to check if there is a successful order by the user, and thank them again! 😉 Failing that, a “there is no checkout in progress” error message?
Steps to Reproduce
c.f. setup in https://github.com/django-oscar/django-oscar/issues/3421
Technical details
- Python version: 3.8
- Django version: 3.0
- Oscar version: 2.0
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
Top GitHub Comments
I agree that a 404 is not the correct response here, and can result in weird things happening if you have a proxy cache like Cloudflare, which will cache 404s for a short period. Not keen on 403 either because this will result in an unfriendly message to the user, and the odds are they are not trying something dodgy (e.g., it may just be a stale browser tab that has been reloaded).
I think we should probably 302 redirect to the home page/basket if we cannot find an order in the session.
Don’t think an error message is necessary tbh