W-21432256: Few follow up fixes to address Basket V2-V1 gaps and content security policy headers

[amittapalli]

W-21432256: Few follow up fixes to address Basket V2-V1 gaps and content security policy headers

Description

• Update the code to use v2 cache key for basket v2
• Fix comments in the code to indicate v2
• Fix content security policy headers for google pay related sources

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

• (change1)

How to Test-Drive This PR

• (step1)

Checklists

General

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

Accessibility Compliance

You must check off all items in one of the follow two lists:

• There are no changes to UI

or...

• Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• Changes comply with WCAG 2.0 guidelines levels A and AA
• Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

• Changes include a UI text update in the Retail React App (which requires translation)

[cc-prodsec]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[sf-mkosak]

I guess same question. Do we need www. and google.com? Just want to confirm.

[amittapalli]

I added them based on what I saw in the browser for CSP errors. It would help if someone else can run the checks during our testing phase or locally. We initially had *.google.com which is not safe but google pay seems to be depending on several url patterns

[sf-mkosak]

are these both needed?

[amittapalli]

I added them based on what I saw in the browser for CSP errors

[vmarta]

When specifying a path for the CSP header, a trailing slash is significant. It means like matching the any requests that start with this path.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy?authuser=0#host-source

Paths that end in / match any path they are a prefix of. For example:
example.com/api/ will permit resources from example.com/api/users/new.

Paths that do not end in / are matched exactly. For example:
https://example.com/file.js permits resources from https://example.com/file.js but not https://example.com/file.js/file2.js.

So I'm guessing google.com/pay/ is sufficient, unless there's a request specifically for exactly google.com/pay.

[joeluong-sfcc]

Thanks for updating the Shopper Baskets V2 hooks, the changes LGTM, did basic smoke testing and confirmed the following:

1. new baskets/v2 cache key is being used instead of old cache keys
2. guest checkout works
3. registered checkout works

[vcua-mobify]

Thanks for updating the comments in default.js around using a vanity domain / ecom domain.

The changes in ssr.js seem fine to me also aside from what @sf-mkosak called out with with the google.com/pay csp entries.

[vmarta]

@joeluong-sfcc do we need the slash '/' at the end or not? Wondering why previously it had the slash at the end

[vmarta]

@amittapalli please add the trailing slash to all the query keys for consistency sake. Yes, functionally, it doesn't matter because query key is just a string (not url). But we have an existing pattern/convention, which only this file does not follow. It may be confusing later in the future for us and the end users.

The Convention in This Codebase

  Looking at both files, there's a clear and deliberate pattern for trailing slashes:

  - Trailing slash → a dynamic ID segment follows immediately after
  - No trailing slash → it's a terminal static segment
                                                                                                           In ShopperBaskets:
  '/baskets/',   <-- trailing slash: basketId follows
  basketId,
  '/shipments/', <-- trailing slash: shipmentId follows
  shipmentId,
  '/payment-methods'  <-- no slash: terminal

  In ShopperBasketsV2:
  '/baskets/v2',  <-- NO trailing slash, but basketId still follows  ← inconsistent
  basketId,

  So yes, /baskets/v2 should be /baskets/v2/ to be consistent with the established convention.

  TanStack Query Best Practices (from tkdodo.eu)

  TanStack Query docs don't prescribe a specific string format — keys are opaque array tuples. The
  community best practices focus on:
  1. Hierarchy from generic → specific (which this codebase does well)
  2. Consistency within a project (which is the issue here)

  The URL-path-like format in this codebase is a local convention, not a TanStack recommendation. Since
  the strings are purely used as cache key identifiers (not as actual URLs), trailing slash consistency
  is entirely a project-style concern — but it matters because path() returns a prefix used for cache
  invalidation. An inconsistent format could cause confusion about what's intentional.

  Recommendation

  Fix the inconsistency in ShopperBasketsV2/queryKeyHelpers.ts: change /baskets/v2 → /baskets/v2/ (in
  both the QueryKeys type and all path() implementations). This aligns with the codebase's own convention
   that trailing slashes signal "a dynamic ID follows."

[jeffraab-sfdc]

Might be good to consider a lint rule for this, if that's possible. Not for this case but for future development.

[vmarta]

When specifying a path for the CSP header, a trailing slash is significant. It means like matching the any requests that start with this path.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy?authuser=0#host-source

Paths that end in / match any path they are a prefix of. For example:
example.com/api/ will permit resources from example.com/api/users/new.

Paths that do not end in / are matched exactly. For example:
https://example.com/file.js permits resources from https://example.com/file.js but not https://example.com/file.js/file2.js.

So I'm guessing google.com/pay/ is sufficient, unless there's a request specifically for exactly google.com/pay.