Who can use this feature?
- Available on all plans.
- Requires an admin role to configure.
Note: The actions described in the below article are not retroactive.
Headers and Bodies
Fullstory Dev Tools gives you the power to capture Request Headers, Response Headers, Request Bodies and Response Bodies for individual Network Requests that took place within a user's captured session.
Request/Response Headers
Request and Response Headers are HTTP Headers that include context about requests and may include details such as Accept
, Cache-control
, Server
, Date
, and other helpful metadata for understanding the conditions of a request.
When Request/Response Headers are available, Fullstory will only capture 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 data capture, Fullstory will not capture those details and they will be shown as [blocked]
when you view Network Details.
Additionally, we do not capture the authorization
, cookie
, and proxy-authorization
headers for security reasons, so you will not see these headers listed within Fullstory Dev Tools.
*If your response header isn't shown after being allowlisted, then it's possible that these are cross-origin requests. You can expose the response header using Access-Control-Expose-Headers.
Safe Headers
Here's a list of headers that are considered safe by Fullstory:
"access-control-allow-origin" | "access-control-allow-credentials" | "access-control-expose-headers" |
"access-control-max-age" | "access-control-allow-methods" | "access-control-allow-headers" |
"accept-patch" | "accept-ranges" | "age" |
"allow" | "alt-svc" | "cache-control" |
"connection" | "content-disposition" | "content-encoding" |
"content-language" | "content-length" | "content-location" |
"content-md5" | "content-range" | "content-type" |
"date" | "delta-base" | "etag" |
"expires" | "im" | "last-modified" |
"link" | "location" | "permanent" |
"p3p" | "pragma" | "proxy-authenticate" |
"public-key-pins" | "retry-after" | "permanent" |
"server" | "status" | "strict-transport-security" |
"trailer" | "transfer-encoding" | "tk" |
"upgrade" | "vary" | "via" |
"warning" | "www-authenticate" | "x-b3-traceid" |
"x-frame-options" |
Request/Response Bodies
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 data capture tools that pull in Request/Response Headers and Bodies by default (often bringing sensitive personal data with them), Fullstory gives you the ability to allowlist only the specific parts of the Request/Response Bodies that you know are safe to capture and that will be useful for your own debugging process.
Allowlisting the Request/Response Bodies
To get started with allowlisting, first you will need to enable Network Data Capture under Settings > Data Capture and Privacy > Data Capture.
It's important to note—enabling this Network Data Capture option alone will only result in:
- Methods
- Safe headers
- Allowlisted Request/Response bodies (if configured)
- Request/Response size (for same-origin requests)
For security reasons, you'll need to explicitly allowlist individual Request/Response bodies for more details to display in Dev Tools.
In the case where Network Data Capture is disabled, and you're allowlisting individual Request/Response bodies in your Privacy settings, it will not immediately result in any effect.
Next: Identify the request that you'd like to begin capturing Request and/or Response Bodies. Take a moment to consider—do you want to capture the entire bodies? Or, only specific fields?
Make note of both the URL path and the names of the fields you'd like to allowlist, if applicable.
Then, log into Fullstory and:
- Navigate to Settings > Data Capture and Privacy > Privacy. Scroll down until you find the section labeled "Network Allowlist."
- Click "Add URL Pattern" to add a new allowlisted request.
- Enter the request URL path you'd like to allowlist as a regex pattern. For example, if your request URL is
https://www.example.com/api/[cust-id]/login
then you should enter a URL pattern that looks like.*www\.example\.com/api/.*/login
. - Use the radio buttons to select whether you'd like to capture the full body or only specific fields.
- If defining specific fields, enter a list of the fields you'd like to allowlist with each field on a new line.
- Click 'Save allowlisted request' to begin capturing Request/Response bodies from that URL pattern.
Syntax & Semantics
URL Patterns
- Regular expression, matching against a full URL
- E.g.,
.*www\.example\.com/api/.*/login
- (note: Fullstory uses JavaScript regex syntax which permits unescaped
/
)
Request/Response Bodies Fields
- allowlist => element(/element)*
- element =>
- fieldName (match a specific field by name)
- * (match any field)
- ** (match any number of fields, including children)
- E.g.,
foo/bar
,foo/bar/*/baz
,foo/**
Example
Let's look at a simple login request.
URL
For example, if the login URL is:
https://www.example.com/api/[cust-id]/login
with the following requests and responses:
Request
{ creds: { user: “foo@customer.com”, password: “s3kr1t!” } }
Response
{ success: false, error: { msg: “something went wrong” } }
Then, to allowlist only the fields user
, success
, error
, and msg
but not password
, your allowlisted request in Fullstory would require these settings:
URL Pattern
.*www.example.com/api/.*/login
Request bodies - Specific fields
creds/user
Response bodies - Specific fields
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 still be displayed as [redacted]
.
bar
property captured:foo
bar
bar
baz
Editing or Removing Network Allowlists
After an allowlisted request has been saved, it can be edited, disabled, or removed at any time.
Under Settings > Data Capture and Privacy > Privacy > Network Allowlist, you can click on any configured allowlist in the table to open the settings to modify the allowlisted request.
To disable an allowlisted request but keep the URL pattern configuration, use the radio buttons to set the allowlisted request to capture "Nothing."
To remove the allowlisted request completely, click to modify the allowlisted request and then click "Delete".
Note: The actions described in the above article are not retroactive.