Filter the app's filter_parameters from logged query strings and Referer/Location URLs

[PetrHeinz]

Rails filters the params it logs with config.filter_parameters, but the request rows that logtail-rack writes carry the raw query string, and headers_json carries the raw Referer and Location URLs. Yesterday's red-team found password=hunter2 and token= values in plain text in query_string, Referer and Location on all seven Rails versions it tested, while the params of the same request showed [FILTERED].

logtail-rack 0.2.9 adds HTTPEvents.query_string_filters (logtail/logtail-ruby-rack#29), with a default list of its own. This PR makes Rails apps use their own filter_parameters for it, so URLs are filtered the same way as params.

What changes:

• During integration, which runs in the :logtail initializer after the app's config initializers, HTTPEvents.query_string_filters is set to Rails.application.config.filter_parameters. Procs are left out: in Rails they rewrite values, while query string filters only match names.
• If the app has already changed query_string_filters from rack's DEFAULT_QUERY_STRING_FILTERS, for example in an initializer, its list is kept.
• The logic lives in a small Logtail::Integrations::Rails.filter_parameters_in_urls(filter_parameters) method, so it can be tested on its own.

Behaviour and compatibility:

• Query parameters whose names match filter_parameters are logged as [FILTERED] in query_string and in the queries of Referer and Location. Before, they were logged raw.
• Rails' default list for new apps includes :email, so email addresses in query strings now become [FILTERED] too. Rack's own default doesn't include email.
• The app's list fully replaces rack's default. An app that only filters :password (the default before Rails 7) still logs token= raw, like Rails logs its params. An app with an empty filter_parameters gets no URL filtering. To filter more, add names to filter_parameters or set query_string_filters in an initializer.
• Names are matched as the full decoded name, so dotted "deep" filters such as credit_card.code don't match credit_card[code] in a query string. Plain names, partial names and Regexps work as they do for params.

Targets the 0.3.0 minor; merge after 0.2.15 is released.

Depends on logtail-rack 0.2.9, which isn't released yet. The TEMP: run CI against the logtail-rack branch until 0.2.9 is released commit points the root Gemfile and every gemfiles/*.gemfile at the claude/query-string-filters branch of logtail-ruby-rack, so CI runs against the real API. The gemspec floor isn't bumped here: at merge time, after logtail-rack 0.2.9 is released, the TEMP commit gets replaced by a follow-up commit that requires logtail-rack ~> 0.2, >= 0.2.9. Until then this must not be merged.

It also carries the "Expect real response durations in the request specs" commit that the other open logtail-rails PRs share, byte for byte: logtail-rack 0.2.8 times responses with the monotonic clock, which Timecop doesn't freeze, so the three specs expecting 0.0ms now fail against the released rack too.

The first commit only adds the tests and is expected to fail on CI; the TEMP commit and the fix come after it.

🤖 Generated with Claude Code