Opened 6 years ago

Closed 6 years ago

#29863 closed New feature (duplicate)

Allow configuration/customization of sensitive settings sanitization for error emails

Reported by: Daniel Harding Owned by:
Component: Error reporting Version: 2.1
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

Description

This request is possibly related to #29714. Our codebase uses custom settings, some of which contain sensitive information which should not appear in error emails, but are not filtered out by Django's default settings sanitization. Django does not currently expose a way to customize which settings get sanitized before being added to error emails. Right now I am able to work around this by monkey-patching the HIDDEN_SETTINGS regex in django.views.debug, but it would be nicer if there were an officially supported way to modify the settings sanitization process.

Change History (6)

comment:1 by Tim Graham, 6 years ago

I'm not immediately convinced. The documentation explains, that settings including 'API', 'KEY', 'PASS', 'SECRET', 'SIGNATURE', and 'TOKEN' will be excluded. I think taking no action here and promoting the choose of appropriate names may be better. In the case of third-party apps, for example, we don't want to the app to choose setting names that won't be excluded by default and have to say, "don't forget to customize error reporting for better security."

comment:2 by Daniel Harding, 6 years ago

In my case, there is not an "appropriate" name that is matched by the exclusion pattern. The setting in question is something like XYZ_WEBHOOK, where the webhook URL is private. FWIW this is not for a third-party app. I do see your point regarding third-party settings. My workaround is sufficient for my needs, so I'm happy if you decide to take no action. It was just a minor pain-point where I wondered if there might be a possibility for improvement.

comment:3 by Carlton Gibson, 6 years ago

Hi Daniel.

On top of this, is there anything here that wouldn't be solved if we had a solution to #29714? i.e. if you could customise the ExceptionReporter output what more would you need? (If nothing then it's a duplicate right?)

comment:4 by Tim Graham, 6 years ago

It's unclear to me what customization hooks might be added as part of that ticket -- "Make it easier to customise ExceptionReporter output" is very broad and could mean many different things.

comment:5 by Carlton Gibson, 6 years ago

Well, subclassing ExceptionReporter to override get_traceback_data() — in which you could filter any value you liked… — was the general idea. (Hence my thinking there’s maybe not much extra that would/could be needed here.)

comment:6 by Carlton Gibson, 6 years ago

Resolution: duplicate
Status: newclosed

Hi Daniel. I'm going to close this as a duplicate of #29714. Come back to us if there is more and we can always re-open. Thanks.

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