Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix recompressing response to happen after replacing sensitive data #951

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cgunther
Copy link
Contributor

Using a combination of recompress_response and filter_sensitive_data, previously VCR would recompress the response first, then try to replace the sensitive data placeholders with the actual value, however once it's recompressed, the placeholders can't be found anymore to replace. Therefore, once your app/library decoded the recompressed response itself, the placeholders were still there, instead of the expected values.

This happened because both actions were handled by before_playback hooks. The recompress hook was registered first upon initialization of the config instance, then the sensitive data hook was registered upon calling filter_sensitive_data (always after initiating the config instance), leading VCR to run them in order, recompressing then replacing.

To ensure recompressing always happens last, after all before_playback hooks run, I added a new specific hook, recompress_response, that gets invoked right after invoking the before_playback hook. This assumes you'd never want to run a before_playback hook after recompressing.

My usecase is that I'm using the braintree gem, which requires gzipped responses, however the response has "sensitive" data that I want to commit with a placeholder since the value might vary across developer machines, so I use decode_compressed_response and filter_sensitive_data so that my committed cassettes use a placeholder, then combine it with recompress_response so the braintree gem can see the responses as gzipped upon playback, with the placeholders replaced.

Using a combination of `recompress_response` and `filter_sensitive_data`,
previously VCR would recompress the response first, then try to replace
the sensitive data placeholders with the actual value, however once it's
recompressed, the placeholders can't be found anymore to replace.
Therefore, once your app/library decoded the recompressed response
itself, the placeholders were still there, instead of the expected
values.

This happened because both actions were handled by `before_playback`
hooks. The recompress hook was registered first upon initialization of
the config instance, then the sensitive data hook was registered upon
calling `filter_sensitive_data` (always after initiating the config
instance), leading VCR to run them in order, recompressing then
replacing.

To ensure recompressing always happens last, after all `before_playback`
hooks run, I added a new specific hook, `recompress_response`, that gets
invoked right after invoking the `before_playback` hook. This assumes
you'd never want to run a `before_playback` hook after recompressing.

My usecase is that I'm using the braintree gem, which [requires gzipped
responses][1], however the response has "sensitive" data that I want to
commit with a placeholder since the value might vary across developer
machines, so I use `decode_compressed_response` and
`filter_sensitive_data` so that my committed cassettes use a
placeholder, then combine it with `recompress_response` so the braintree
gem can see the responses as gzipped upon playback, with the
placeholders replaced.

[1]: https://github.com/braintree/braintree_ruby/blob/7d4182b7407bd66061faacadec54960e6c876f72/lib/braintree/http.rb#L174-L180
@cgunther cgunther force-pushed the recompress-and-filter branch from 6182b3d to 34b284d Compare October 30, 2022 00:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant