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 )
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 , 15 years ago
Component: | django.contrib.sessions → Core framework |
---|---|
milestone: | 1.2 |
Summary: | Session Middleware ignores DEBUG setting - Potential Security Issue → Exceptions raised in response middleware don't invoke site 500/404 handlers. |
Triage Stage: | Unreviewed → Accepted |
by , 14 years ago
Attachment: | 12909.diff added |
---|
django/core/handlers/wsgi.py handle exception thrown from middleware
comment:2 by , 14 years ago
Cc: | added |
---|---|
Has patch: | set |
comment:3 by , 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 , 14 years ago
Type: | → Bug |
---|
comment:5 by , 14 years ago
Severity: | → Normal |
---|
comment:6 by , 14 years ago
Cc: | added |
---|
comment:7 by , 14 years ago
Description: | modified (diff) |
---|---|
Needs tests: | set |
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.