Opened 11 years ago
Closed 11 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.user
which 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.