feat: Mask page URLs in session recordings #811
Merged
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.
Changes
href
attribute that is now masked bymaskNetworkRequestFn
$pageview
events have ahref
attribute that is now masked bymaskNetworkRequestFn
Notes
Right now, properties on events can be filtered using
sanitize_properties
to redact any sensitive information in URLs, andmaskNetworkRequestFn
does the same for captured network events. But rrweb has a Meta event that leaks the full page URL, and there is also a mechanism that translates$pageview
events into rrweb custom events, that captureswindow.location.href
directly. I passed these throughmaskNetworkRequestFn
to redact sensitive information as necessary. Without this patch, neither of these values can be sanitized by the currently available options.To be honest, I don't know why
window.location.href
is used directly when$pageview
events are translated into rrweb custom events - there is a perfectly good$current_url
property that has already passed throughsanitize_properties
on the event object. As an alternative to passing that throughmaskNetworkRequestFn
one could also just use that value (it might also be more "correct" in the sense that I don't know if there is a guarantee thatwindow.location.href
would always have the desired value when it is used here). But that still leaves the Meta event, which captureswindow.location.href
mercilessly.I couldn't find any test infrastructure for events coming from / forwarded to rrweb, so I don't really know how to add tests for this without doing a lot of groundwork first.
Checklist