On Jun 2, 3:33 pm, Luke Plant <l.plant...@cantab.net> wrote: > 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.
An all or nothing filter, while helpful does reduce the usefulness of the traceback. I'd prefer to have the option to filter out only the offending variables in an easy to maintain way. Lets assume that there are three functions with some vars that need to be filtered out (func_a, func_b, func_c). These functions are used by a dozen views across various apps in your project; some use all, most use one or many of these functions. I'm looking to avoid needing to maintain a hierarchy of filters (or a single filter that knows about all sensitive functions) to handle all of the potential sensitive frames that might be called by a given view. I also don't want to add a generic filter to every view in the project to prevent the situation where a new view uses a function that a few frames down uses one of the sensitive functions without the author realizing it. I guess what I proposed would be best applied to django.views.debug.ExceptionReporter, so it is not necessary to apply a view filter if you only need to filter out variables in various frames. On Jun 2, 3:33 pm, Luke Plant <l.plant...@cantab.net> wrote: > > 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. It's possible. The traceback provides the function name, locals and globals as seen by the frame. function_name = tb.tb_frame.f_code.co_name func = tb.tb_frame.f_globals.get(function_name) On Jun 2, 3:33 pm, Luke Plant <l.plant...@cantab.net> wrote: > 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). A disadvantage of using a local variable is that the only way a developer can flag a 3rd party function is by forking the code. Patching an attribute on to a function is a much more flexible option. 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 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.
