OK, I'm seriously ruining my first attempt at submitting a patch. :-) I changed the capitalization of a config key without updating the unit tests so <blush> here's another patch file. Apologies for the spam. I think this is the last one I'll need to post on this issue ... hopefully ... :-)
On Wed, Jul 1, 2009 at 11:16 AM, Brian Phillips <bpphillips...@gmail.com<bpphillips%2...@gmail.com> > wrote: > Sorry for the repost but I realized I hadn't updated to svn HEAD before > making the patch file. In case that matters, the attached should apply > cleanly against r10759. > Thanks! > > > On Wed, Jul 1, 2009 at 11:03 AM, Brian Phillips > <bpphillips...@gmail.com<bpphillips%2...@gmail.com> > > wrote: > >> I've taken a stab at implementing this as I recently was wanting this >> functionality. See attached for the patch (including docs and unit tests). >> Feedback welcome. >> >> On Fri, Jan 30, 2009 at 5:20 PM, Byron Young <byron.yo...@riverbed.com>wrote: >> >>> Tomas Doran wrote on 2009-01-29: >>> > >>> > On 29 Jan 2009, at 18:53, Byron Young wrote: >>> > >>> >> Hi - I'm not sure what the repost policy on patches, but I have the >>> >> feeling this one slipped through the cracks. Let me know if it's >>> >> generally annoying to repost stuff. >>> > >>> > No, reposting if things get dropped on the floor good :) >>> > >>> > If you have time, then arriving on #catalyst-dev and making noise >>> > also gets stuff done. >>> > >>> >> This is a patch that allows you to suppress printing the value of >>> >> certain query or body parameters when running Catalyst in debug >>> >> mode - For example, if you want to hide passwords sent from the >>> >> login page, you can put this in your app config (yaml): >>> > Having been discussed in #catalyst-dev, we think that the patch could >>> > be made both more generic, and more elegant. >>> > >>> > The key thing is to split the table drawing, and the data filtering >>> > into separate methods (maybe filter_debug_data?). >>> > >>> > This would then allow you to filter per-type, and support things such >>> as >>> > redact_parameters (all), redact_body_parameters, >>> > redact_query_parameters, and even potentially to add support for >>> > filtering things like the URI (I can see use-cases where that'd be >>> > significant - e.g. not wanting to log session IDs which are in URIs).. >>> > >>> > Have a look at the way the debug screen stuff works (in >>> > Catalyst::Engine), this is more elegant and would also benefit from >>> > being able to have things redacted I guess - as with the current >>> > patch, you're going to display the things you're redacting in the >>> > logs to the end user... >>> > >>> > Cheers >>> > t0m >>> > >>> >>> Tom, >>> >>> Thanks for the feedback. I think you're referring to $c->dump_these() >>> and it's usage in finalize_error(). I'll refactor log_parameters() to call >>> a separate method that will return the params to log, akin to dump_these(). >>> Not sure when I'll have time for it since my current solution is working >>> for me and I have some big deadlines coming up. Hopefully within the next >>> month. >>> >>> Thanks >>> byron >>> >>> >>> _______________________________________________ >>> List: Catalyst@lists.scsys.co.uk >>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >>> Searchable archive: >>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >>> Dev site: http://dev.catalyst.perl.org/ >>> >> >> >
0001-param-filtering-docs-tests.patch
Description: Binary data
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
