Opened 10 years ago

Closed 10 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



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:

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/", 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/", 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/", line 137, in get_page_from_request
    draft = use_draft(request)
  File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-packages/cms/utils/", 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

Change History (1)

comment:1 Changed 10 years ago by Marc Tamlyn

Resolution: wontfix
Status: newclosed

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.

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