Opened 15 years ago

Last modified 12 years ago

#12909 closed Bug

Exceptions raised in response middleware don't invoke site 500/404 handlers. — at Version 7

Reported by: jhovanny Owned by: nobody
Component: Core (Other) Version: 1.2-beta
Severity: Normal Keywords:
Cc: crucialfelix@…, gary.wilson@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Julien Phalip)

If there is an error connecting to the session database, the session middleware throws an Exception that's visible regardless of the DEBUG setting. The stack trace appears in a blank page (non-conforming to the standard debug template). To reproduce this ticket, drop the django_session table and try to login to any django application. The expected behavior is not to show a stack trace when DEBUG=False

Traceback (most recent call last):

  File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 280, in run
    self.result = application(self.environ, self.start_response)

  File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 674, in __call__
    return self.application(environ, start_response)

  File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/wsgi.py", line 245, in __call__
    response = middleware_method(request, response)

  File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/middleware.py", line 36, in process_response
    request.session.save()

  File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/db.py", line 57, in save
    session_key = self.session_key,

  File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/base.py", line 152, in _get_session_key
    self._session_key = self._get_new_session_key()

  File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/base.py", line 144, in _get_new_session_key
    if not self.exists(session_key):

  File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/db.py", line 30, in exists
    Session.objects.get(session_key=session_key)

  File "/usr/local/lib/python2.6/dist-packages/django/db/models/manager.py", line 132, in get
    return self.get_query_set().get(*args, **kwargs)

  File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 334, in get
    num = len(clone)

  File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 79, in __len__
    self._result_cache = list(self.iterator())

  File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 267, in iterator
    for row in compiler.results_iter():

  File "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", line 685, in results_iter
    for rows in self.execute_sql(MULTI):

  File "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", line 740, in execute_sql
    cursor.execute(sql, params)

  File "/usr/local/lib/python2.6/dist-packages/django/db/backends/util.py", line 19, in execute
    return self.cursor.execute(sql, params)

  File "/usr/local/lib/python2.6/dist-packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in execute
    return self.cursor.execute(query, args)

DatabaseError: relation "django_session" does not exist
LINE 1: ...ession_data", "django_session"."expire_date" FROM "django_se...
                                                             ^

Change History (8)

comment:1 by Russell Keith-Magee, 15 years ago

Component: django.contrib.sessionsCore framework
milestone: 1.2
Summary: Session Middleware ignores DEBUG setting - Potential Security IssueExceptions raised in response middleware don't invoke site 500/404 handlers.
Triage Stage: UnreviewedAccepted

Correcting the title to remove the scaremongering. This isn't even remotely a security issue. There is nothing private or exploitable being released here.

On that note - it doesn't matter now, but *PLEASE* don't report security issues in Trac. [See Django's security policy http://docs.djangoproject.com/en/dev/internals/contributing/#id2] for instructions on how to report potential security problems.

Now - back to the ticket.

The issue here is that exceptions raised in a process_response component of a middleware don't invoke the 500 handling infrastructure.

by crucialfelix@…, 14 years ago

Attachment: 12909.diff added

django/core/handlers/wsgi.py handle exception thrown from middleware

comment:2 by crucialfelix@…, 14 years ago

Cc: crucialfelix@… added
Has patch: set

comment:3 by crucialfelix@…, 14 years ago

side note to jhovanny:

Your server's 500 page should just say 500 Internal Error. I'm not sure how it could be displaying the python exception. The error would go to your server log.

Use paste to wrap django's wsgi for an added layer of protection. Django is not infallible. Spills happen, admins like to be notified.

from paste.exceptions.errormiddleware import ErrorMiddleware
application = ErrorMiddleware( django_wsgi, debug=False, error_email='crucialfelix@…', show_exceptions_in_wsgi_errors=True, from_address='admin@…',error_message='500 Internal Error' )

This gives a very sober and simple 500 error page for the user and emails me a full stack trace. Exceptions like these are rare. You can customize the 500 page a bit if you need to.

comment:4 by Luke Plant, 14 years ago

Type: Bug

comment:5 by Luke Plant, 14 years ago

Severity: Normal

comment:6 by Gary Wilson, 14 years ago

Cc: gary.wilson@… added

comment:7 by Julien Phalip, 14 years ago

Description: modified (diff)
Needs tests: set
Note: See TracTickets for help on using tickets.
Back to Top