Scrub body_data / data params too (e.g. POSTed JSON) #3

If we have `$c->req->body_data` - for e.g. the request was a POST with a JSON body which Catalyst has decoded into `$c->req->body_data` - then scrub HTML in there too (but applying the same `ignore_params` checks so that you can exempt certain JSON body params from scrubbing). Also moved the ignore_params tests into t/03_params.t, and added the tests for this new feature there too - don't need so many individual test apps, when most features can be tested with a single test app.

Use `is()` not `ok()` so that, if the request status is *not* what we expect, we get to see what it actually was.

If Catalyst::Action::REST / Catalyst::Controller::REST is in use, the request object will have a `data()` method for deserialised data as added by the Catalyst::TraitFor::Request::REST role which ought to be scrubbed too. To support this, (a) the scrubbing needs to happen later in the request flow - now `hooking dispatch()` instead of `prepare_parameters()` (b) to avoid the data not being read if the request body had already been read by `$c->req->body_data`, the fix in this PR is needed: perl-catalyst/catalyst-runtime/pull/186 Until such time, dirtily monkey-patch the `seek()` in.

This seems to be the right time to go scrubbing, without the scrubbed data getting accidentally clobbered, and/or happening too late.

Our monkey-patch pokes at Catalyst, so Catalyst needs to be loaded first. In the usual way of loading the plugin, e.g. listing the plugins you want on the `use Catalyst` line, that's fine, but here we're testing just that the plugin compiles, so we will need to load Catalyst first.

Yes, we're redefining a sub, intentionally, to monkey-patch, so silence that warning.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Scrub body_data / data params too (e.g. POSTed JSON) #3

Scrub body_data / data params too (e.g. POSTed JSON) #3

Commits on Sep 18, 2023