When you configure ExVCR with filter_sensitive_data and/or filter_request_headers any sensitive information is removed from request headers when stored on disk as a cassette. If you attempt to use the stored cassette, and specify match_requests_on: [:headers], it won't match because the header values have been filtered and won't be the same as the unfiltered raw request headers.
This pull request applies sensitive data filtering to the request headers before comparing with recorded cassette for equality. I've included tests for each of the three adapters to verify the change.
Coverage increased (+0.05%) to 93.686% when pulling 3479c6f48b8cb147179b38e28b775a46cddbf1b2 on slashdotdash:feature/filter-headers-before-match into 7bd7aa2f518886d5fd8dc9dfde04be828a7817b1 on parroty:master.
Coverage increased (+0.05%) to 93.686% when pulling 3479c6f48b8cb147179b38e28b775a46cddbf1b2 on slashdotdash:feature/filter-headers-before-match into 7bd7aa2f518886d5fd8dc9dfde04be828a7817b1 on parroty:master.
When you configure ExVCR with
filter_sensitive_data
and/orfilter_request_headers
any sensitive information is removed from request headers when stored on disk as a cassette. If you attempt to use the stored cassette, and specifymatch_requests_on: [:headers]
, it won't match because the header values have been filtered and won't be the same as the unfiltered raw request headers.This pull request applies sensitive data filtering to the request headers before comparing with recorded cassette for equality. I've included tests for each of the three adapters to verify the change.