Opened 12 years ago
Closed 12 years ago
#22011 closed Uncategorized (wontfix)
no request.user on error pages
| Reported by: | Viktor | Owned by: | nobody |
|---|---|---|---|
| Component: | Uncategorized | Version: | 1.5 |
| 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
Hi,
I don't know how much complexity this needs to be reproduced, but I'll try to describe the key elements.
Basically, I would like custom error pages to be handled by the django backend, especially by django-cms. I've followed this setup:
http://ilian.i-n-i.org/custom-404-not-found-page-with-django-cms/
Moreover, I've tried the same for 500 pages too. Now, I've found the following:
- if DEBUG = True, then django's 404 page shows up
- if DEBUG = False, then neither of my views is called, and some weird 500 page shows up
I could not get my 500 page to be called at all. (I've tried it by not setting up the 404 page to be server on 404 calls.)
The traceback follows:
File "/Users/viktornagy/projects/puli/vagrant/project/cms2/cms2/views.py", line 15, in handler500
response = details(request, Page.objects.filter(reverse_id='500')[0].get_absolute_url())
File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-packages/cms/views.py", line 42, in details
page = get_page_from_request(request, use_path=slug)
File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-packages/cms/utils/page_resolver.py", line 137, in get_page_from_request
draft = use_draft(request)
File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-packages/cms/utils/page_resolver.py", line 29, in use_draft
authenticated = request.user.is_authenticated() and request.user.is_staff
AttributeError: 'WSGIRequest' object has no attribute 'user'
[11/Feb/2014 14:28:22] "GET /asdf/ HTTP/1.1" 500 59
Unlike the 404 page, Django deliberately hobbles the rendering of the 500 page.
request.userwhich is provided by a piece of middleware is not available. It is recommended that you do not interact with the database during the rendering of a 500 as it is impossible to know why you're on the page and what pieces of middleware have run.If for example there is a 500 because the database is unavailable, a 500 page which loads the user from the database would also error during its rendering - what do we do then? You could register a custom 500 handler which tried to carefully render a page using the user if it could, and fell back to a flat 500 page if not, but personally I would not advise it.
I'm going to close this ticket as won't fix because I think Django's way of handling of the 500 page is correct - it should do its best to avoid any possible errors.