On Jun 1, 5:53 am, Luke Plant <[email protected]> wrote: > Would it possible to make the sensitive decorator add some kind of > strategy object to the request, which itself is responsible for the > filtering, rather than a simple boolean flag? The strategy object > interface might be: > > class ExceptionReporterFilter(object): > def show_request(self, request): > # return True or False > > def filter_request_POST(self, request, post_dict): > # if show_request is True, this is passed request.POST > # and returns a sanitised version > > def show_traceback(self, request): > # True or false > > def show_traceback_vars(self, request): > # called only if show_traceback() returns True > > def filter_traceback_vars(self, request, tb_frame, vars): > # filters vars to be shown at each level. > > OK, could get carried away there - maybe we should start simple, e.g. > just 'show_request' and 'show_traceback_vars'. But something like that > would allow us to provide a working 'sensitive' decorator, but with a > mechanism that allows for something more fine-grained, and allows us to > add more features to it easily in the future. For the admin and CBVs it > would work as well, since there are always places you can override a > method and attach something to the request object.
Being able to filter at the scope of a view is a must and I like this approach, but I'm not sure that I like having to control filtering of the entire traceback at the scope of a view. That could lead to needing to repeat parts of filtering on lots of views, if code is reused often. I wonder if it would make sense to handle the traceback and vars filtering with a mechanism similar to __traceback_hide__. This would allow controlling leakage per frame and make it less likely to be missed on view. Example: def do_stuff(): ... do_stuff.__traceback_filter_vars__ = ['credit_card', 'password', 'launch_codes'] > If I'm thinking correctly, with an additional method like > 'filter_settings', it might be possible to have a default > ExceptionReporterFilter that does the filtering of settings that is > currently hardcoded into django/views/debug.py. You're correct. 'cleanse_settings' with the hardcoded HIDDEN_SETTINGS re. Regards. Michael Manfre -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
