Cache SLAS callback using request processor

[kevinxh]

Background

The retail react app uses SLAS for shopper authentication and the login flow has an endpoint /authorize returns 303 on successful authorization attempts and redirect user to a pre-registered redirect_uri that looks like https://mydomain/callback?usid=1&code=2. We do NOT need to follow the redirect because we have the information from the response headers.

However, for security reasons, browsers forcefully follow the redirect and there is no option to stop that. This PR attempts to aggressively cache the /callback endpoint on the CDN to make the network round trip faster.

Solution

CloudFront (MRT's CDN) caches pages based on the URL and headers, since every time /callback is hit with unique query parameters usid and code, by default the endpoint is not cached. We use the request processor (CloudFront's edge computing solution - Lambda@Edge) to remove the query parameters before the request hits the CDN. This will make the CDN cache the /callback endpoint as if there were no query parameters.

Types of Changes

Performance enhancement.

Changes

• Update request processor to remove usid and code parameters on the /callback endpoint.

How to Test-Drive This PR

Testing method: query the /callback?usid=1&code=2 endpoint multiple times and vary the value of usid and code. Without the change, you will never get CDN cached response.
With the change, you always get cached responses.

Before

Environment: https://pwa-kit.mobify-storefront.com

This environment does NOT have the change from this PR.

# First try
curl -s -D - -o /dev/null https://pwa-kit.mobify-storefront.com/callback?usid=1&code=2

# Try again using different parameters
curl -s -D - -o /dev/null https://pwa-kit.mobify-storefront.com/callback?usid=3&code=4

Inspect the headers, you should always see x-cache: Miss from cloudfront.

HTTP/2 200
content-type: application/json
content-length: 0
server: CloudFront
date: Thu, 12 Jan 2023 06:46:47 GMT
referrer-policy: no-referrer
x-dns-prefetch-control: off
x-permitted-cross-domain-policies: none
x-xss-protection: 0
expect-ct: max-age=0
strict-transport-security: max-age=15552000; includeSubDomains
x-frame-options: SAMEORIGIN
x-amzn-remapped-content-length: 0
content-security-policy: img-src 'self' *.commercecloud.salesforce.com data:;script-src 'self' 'unsafe-eval' storage.googleapis.com;upgrade-insecure-requests;default-src 'self';base-uri 'self';block-all-mixed-content;font-src 'self' https: data:;frame-ancestors 'self';object-src 'none';script-src-attr 'none';style-src 'self' https: 'unsafe-inline'
x-amzn-remapped-connection: close
x-download-options: noopen
x-amz-apigw-id: enfxoHcRIAMF1Sw=
x-content-type-options: nosniff
x-amzn-trace-id: Root=1-63bfacd7-7ec58b2c5c5f2aed4399aef8;Sampled=0
x-amzn-remapped-date: Thu, 12 Jan 2023 06:46:47 GMT
x-amzn-requestid: fcd24de7-2657-4992-a6e7-7f4c452eda6f
x-cache: Miss from cloudfront            <================================= this means the endpoint is not cached
via: 1.1 9b34a4c8b07eed6c2ff20b5adbbfa7c4.cloudfront.net (CloudFront)
x-amz-cf-pop: YVR50-C1
x-amz-cf-id: FPJOo_3GFoG5nLDXbOhJMICos8cAonoKlGG9zctyo-4OjiqqfA8XYw==

After

Environment: https://scaffold-pwa-test-env.mobify-storefront.com

This environment does have the change from this PR.

# First try
curl -s -D - -o /dev/null https://scaffold-pwa-test-env.mobify-storefront.com/callback?usid=1&code=2

# Try again using different parameters (you might need to wait for a few seconds b/c there is a delay for CDN to populate cache)
curl -s -D - -o /dev/null https://scaffold-pwa-test-env.mobify-storefront.com/callback?usid=3&code=4

Inspect the headers, on the second try, you should see x-cache: Hit from cloudfront. This proves that the CDN caches the /callback regardless of the usid and code query parameters.

Checklists

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

[kevinxh]

This QueryParameters class is a custom version of the javascript native API URLSearchParams. I don't see a reason why we have to use QueryParameters?

The request processor should be super lean and fast since it is called on every request at the edge, we should not advocate for importing libraries from this file, especially when we have native alternatives.

[bendvc]

Looking at the code in the SDK, the reason that we are using this custom QueryParameters class is because the order of queries is important (?a=1&b=2 might be a hit, but ?b=1&a=2 might not). The QueryParameters is here to maintain order when you are manipulating the search string.

Although not using that class doesn't effect this particular situation, the removal of the example boilerplate code might mean that partners that do decide to make changes to the request processor will do so incorrectly not knowing about this restriction.

[wjhsf]

URLSearchParams also preserves the order; the key differences seem to be how null is handled and how spaces are encoded.