Fix recompressing response to happen after replacing sensitive data #951
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using a combination of
recompress_response
andfilter_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 callingfilter_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 thebefore_playback
hook. This assumes you'd never want to run abefore_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
andfilter_sensitive_data
so that my committed cassettes use a placeholder, then combine it withrecompress_response
so the braintree gem can see the responses as gzipped upon playback, with the placeholders replaced.