The following documentation outlines how to whitelist Response and Request Bodies for Network Details in Dev Tools. Dev Tools is an add-on available for FullStory accounts. If you do not currently have the Dev Tools add-on enabled for your account, you can purchase Dev Tools in the app or request a Dev Tools trial.
FullStory Dev Tools gives you the power to record Request Headers, Response Headers, Request Bodies and Response Bodies for individual Network Requests that took place within a user's recorded session.
Request and Response Headers are HTTP Headers that include context about about requests and may include details such as Accept
, Cookie
, Cache-control
, Server
, Date
and other helpful metadata for understanding the conditions of a request.
When Request/Response Headers are available, FullStory will only record header fields that are known to be safe and make those available to view under Network Request details. For any Request/Response Header fields that aren't clearly known to be safe for recording, FullStory will not record those details and they will be shown as [redacted]
when you view Network Details.
Note: at this time, FullStory doesn't offer controls for whitelisting specific Request/Response Headers data.
Request and Response Bodies are the content messages or payloads sent back and forth during a request.
Some of the details in Request and Response Bodies can be super powerful for debugging. However, because these bodies often carry submitted form data, these bodies are likely to contain some sensitive information that FullStory would never want to capture.
Unlike some other recording tools that pull in Request/Response Headers and Bodies by default (often bringing toxic personal data with them), FullStory gives you the ability to whitelist only the specific parts of the Request/Response Bodies that you know are safe to record and that will be useful for your own debugging process.
To get started with whitelisting, first you will need to enable Ajax Recording under Settings > Recording.
It's important to note—enabling this Recording Option alone will not immediately result in any effect. For security reasons, you'll need to explicitly whitelist individual Request/Response bodies.
Next:
Identify the request that you'd like to begin recording Request and/or Response Bodies. Take a moment to consider—do you want to record the entire bodies? Or, only specific fields?
Remember: if the body could contain any sensitive information, you will want to identify specific fields to whitelist and not record the whole body.
Make note of both the URL path and the names of the fields you'd like to whitelist, if applicable.
Then, log into FullStory and:
https://www.example.com/api/[cust-id]/login
then you should enter a URL pattern that looks like .*www\.example\.com/api/.*/login
..*www\.example\.com/api/.*/login
foo/bar
, foo/bar/*/baz
, foo/**
Let's look at a simple login request.
For example, if the login URL is:
https://www.example.com/api/[cust-id]/login
with the following requests and responses:
{ creds: { user: “foo@customer.com”, password: “s3kr1t!” } }
{ success: false, error: { msg: “something went wrong” } }
Then, to whitelist only the fields user
, success
, error
, and msg
but not password
, your whitelisted request in FullStory would require these settings:
.*www.example.com/api/.*/login
creds/user
success
error/msg
After these settings are configured, whenever you view Responses and Requests within the Network Tab in FullStory, you'd expect to see the user credentials, success, and error message come through while the password would remain redacted.
After a whitelisted request has been saved, it can be edited, disabled, or removed at any time.
Under Settings > Privacy > Ajax Request Whitelist, you can click on any configured whitelist in the table to open the settings to modify the whitelisted request.
To disable a whitelisted request but keep the URL pattern configuration, use the radio buttons to set the whitelisted request to record "Nothing."
To remove the whitelisted request completely, click to modify the whitelisted request and then click "Remove whitelisted request."