On 02/06/11 19:45, Michael Manfre wrote: > > > On Jun 1, 5:53 am, Luke Plant <l.plant...@cantab.net> 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'm not quite sure what you're saying. In my proposal above, the 'filter_traceback_vars' would only be used if 'show_traceback_vars' returned True, and by default it would return all vars. So you wouldn't be forced to do any filtering on that level. Since you could re-use your filtering class for multiple views, and you can implement it how you want, there would be no need to repeat the definition of the filtering. > 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'] I'm not sure this even possible - can you go from a traceback frame to the *function* object? __traceback_hide__ is a local attribute, not a function attribute. We could do the same with __traceback_filter_vars__ and make a local variable. But that could be an implementation detail of the ExceptionReporterFilter (just as respecting __traceback_hide__ would be). Luke -- "Trouble: Luck can't last a lifetime, unless you die young." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
