#19866: SuspiciousOperation should not be answered with HTTP 500
---------------------------------+------------------------------------
Reporter: tiwoc | Owner: ptone
Type: Bug | Status: assigned
Component: HTTP handling | Version: master
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Comment (by ptone):
So a near final patch is available here for review:
https://github.com/ptone/django/compare/ticket/19866-susop
@dstufft's feedback on passing the exc as extra_info was that people are
not likely to bother with custom handlers - so the current approach uses a
sub-logger with a matching name.
The prior use of SuspiciousOperation varied in terms of how it was handled
- in many cases it was handled outside of the base WSGI handler, and in
other cases it made it up to the WSGI handler, where it was unhandled,
triggering the unhandled exc code path and returning a 500 (the original
issue of this ticket)
This patch essentially does two things:
It handles a SuspiciousOperation in the WSGI handler and returns a 400
through a similar process as the 404 and 500 handlers, it was deemed not
worthwhile to refactor this resolver branching heavily into something that
references a dict or otherwise, as there were enough differences such that
there would have been little net gain for increasing the indirection. To
fully refactor this would involve URLresolver changes and should be done
in a different patch.
Other uses of SuspiciousOperation were being handled before reaching the
WSGI handler, but there was no reporting of these to the user - this
silent swallowing of potentially security related data is addressed in
this patch by logging any SuspiciousOperation to a django.security logger.
This is handled inside the init of SuspiciousOperation, because in a
number of places SuspiciousOperation was not being handled with any
specific behavior, and the "event" worth logging happens at the time the
SuspiciousOperation is raised, not when it is handled. The base
SuspiciousOperation has been differentiated into subclasses - this was
done initially when the filtering was to be done by handlers, but remains
as a way of matching the subclass to matched sub-logger (and can still be
used in custom handlers).
By default the handler for the security logger is mail-admins. This is to
preserve the existing behavior for those places where SuspOp would be
caught in the WSGI handler, and because security related stuff should be
loud by default - but this also means that situations that raised
SuspiciousOperation, which were being silently caught in the past, will
also now generate admin-mails. There is a documentation example of how to
silence logging associated with specific SuspiciousOperation subclasses.
--
Ticket URL: <https://code.djangoproject.com/ticket/19866#comment:25>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.83d5c02e45ce78059168947a2de58521%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
