Opened 9 years ago

Closed 4 years ago

#23951 closed New feature (duplicate)

SafeExceptionReporterFilter does not have a way to filter and redact exception messages

Reported by: Lukhnos Liu Owned by: nobody
Component: Error reporting Version: dev
Severity: Normal Keywords: logging
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


SafeExceptionReporterFilter provides methods that filter things like POST parameters and traceback variables. However, there does not seem to be a way to filter and redact the exception message itself. Here is an example:

IntegrityError: null value in column "some_column" violates not-null constraint
DETAIL:  Failing row contains (1, 2014-11-10 15:32:29.791438-08, Foo, Bar, null,, t, null, , , 10000.00, 1, 1000.00).

This error is raised by the PostgreSQL backend, which in turn uses psycopg2's IntegrityError, which in turn reports PostgreSQL's own error verbatim. Because it dumps the entire row, this means potentially sensitive information is leaked into logs.

Note that I use a SafeExceptionReporterFilter subclass as my DEFAULT_EXCEPTION_REPORTER_FILTER, so I'm already doing some extra filtering in its get_post_parameters and get_traceback_frame_variables methods.

From the source code, it appears that the exception message is included here: This lives in ExceptionReporter, not the filter. One can run their own Django fork and do something in that method, or patch it during runtime from their project. It may still be better to redact on the filter level, though.

To sum up, I believe there needs to be a way to filter exception messages, so that apps get a chance to pattern-match and redact strings that potentially contain sensitive information.

Change History (4)

comment:1 Changed 9 years ago by Tim Graham

Component: UncategorizedCore (Other)
Triage Stage: UnreviewedAccepted
Type: BugNew feature
Version: 1.7master

comment:2 Changed 8 years ago by Tim Graham

Component: Core (Other)Error reporting

comment:3 Changed 4 years ago by Carlton Gibson

Arguably this would be resolved by a fix to #29714 (for which there's an open PR): users could implement a custom exception reporter to filter as they needed, rather than us adding logic for each possible exclusion use-case.

comment:4 Changed 4 years ago by Carlton Gibson

Resolution: duplicate
Status: newclosed

#30752 (Django 3.1) allows providing a custom ExceptionReporter sublcass. That will be the place to add the logic you need.

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