Skip to content

fix: TRAC-293 Pass customer token through routes and webpages#3013

Merged
chanceaclark merged 1 commit into
canaryfrom
chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display
May 14, 2026
Merged

fix: TRAC-293 Pass customer token through routes and webpages#3013
chanceaclark merged 1 commit into
canaryfrom
chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display

Conversation

@chanceaclark

@chanceaclark chanceaclark commented May 14, 2026

Copy link
Copy Markdown
Contributor

Jira: TRAC-293

What/Why?

Customer-only webpages were inaccessible and didn't appear in the navigation when a customer was logged in, because the routes that resolve them (and the webpage queries themselves) were being executed anonymously. The Storefront API correctly hides customer-restricted content when no customer token is present, so authenticated customers saw 404s or missing entries despite having access.

Two layers needed the customer access token plumbed in:

  1. core/proxies/with-routes.ts — the URL-to-entity resolution that runs on every navigation. The handler is now wrapped in auth(), and req.auth?.user?.customerAccessToken is threaded into getRoute and getRawWebPageContent. Authenticated requests also bypass the shared KV route cache (its key is (pathname, channelId) and isn't namespaced by customer identity, so reading or writing it for a logged-in customer could leak customer-specific resolutions across users). The channel-wide status cache is unaffected, and getStoreStatus is intentionally untouched.
  2. Normal + Contact webpage routes (app/[locale]/(default)/webpages/[id]/{normal,contact}/) — page-data.ts accepts a customerAccessToken and switches fetchOptions to { cache: 'no-store' } when authenticated (matching the product page pattern). page.tsx resolves the token via getSessionCustomerAccessToken() in generateMetadata and the page component, then threads it through getWebPage, getWebPageBreadcrumbs, getWebPageWithSuccessContent, and getContactFields.

The no-store switch on authenticated requests is important: without it, a logged-in customer's response could be served from the shared Next.js fetch cache to subsequent anonymous visitors (or vice versa).

Closes #2325.

Testing

Screenshot 2026-05-14 at 10 45 21

Setup:

  1. In the BC control panel, create a customer group (e.g. "VIP").
  2. Assign a customer to the group.
  3. Create a web page and restrict its visibility to the "VIP" group.
  4. If the page is a child of another page, confirm it shows in the parent's sidebar nav only for VIP members.

Verify:

  • Before the fix: browsing the page URL as the VIP customer returns 404 and the page does not appear in nav.
  • After the fix: browsing as the VIP customer renders the page correctly and the page appears in nav.
  • Browsing as an anonymous user or non-VIP customer still does not see the page.
  • Storefront pages that aren't customer-restricted continue to load identically for both anonymous and authenticated traffic.
  • Hit a customer-restricted page anonymously, then again as an authenticated VIP customer (and back), and confirm each request sees its correct view (i.e. the KV cache from one identity is not served to the other).

Migration

No migration required. No public API surface changed.

Refs TRAC-293

@vercel

vercel Bot commented May 14, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
catalyst Ready Ready Preview, Comment May 14, 2026 4:56pm

Request Review

@changeset-bot

changeset-bot Bot commented May 14, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: ee0dd8d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@bigcommerce/catalyst-core Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@chanceaclark
chanceaclark force-pushed the chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display branch from 702e10f to 27d5c45 Compare May 14, 2026 16:49
@github-actions

Copy link
Copy Markdown
Contributor

Bundle Size Report

Comparing against baseline from bfafc56 (2026-05-14).

No bundle size changes detected.

Customer-only webpages were inaccessible and missing from navigation
when logged in. The with-routes proxy and the normal/contact webpage
page-data queries resolved routes anonymously, so the Storefront API
hid customer-restricted content from authenticated users.

- Wrap the with-routes proxy handler in auth() and thread the customer
  access token into getRoute and getRawWebPageContent
- Bypass the KV route cache when a customer access token is present;
  the cache key isn't namespaced by customer identity, so reading or
  writing it for authenticated requests could leak customer-specific
  route resolutions across users
- Pass the customer access token into normal and contact webpage
  page-data queries, switching to a no-store fetch when authenticated so
  cached anonymous responses are not served to logged-in customers
- Leave getStoreStatus unchanged (does not depend on customer identity)

Refs TRAC-293
Co-Authored-By: Claude <noreply@anthropic.com>
@chanceaclark
chanceaclark force-pushed the chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display branch from 27d5c45 to ee0dd8d Compare May 14, 2026 16:55
@chanceaclark
chanceaclark marked this pull request as ready for review May 14, 2026 17:22
@chanceaclark
chanceaclark requested a review from a team as a code owner May 14, 2026 17:22
@github-actions

github-actions Bot commented May 14, 2026

Copy link
Copy Markdown
Contributor

Unlighthouse Performance Comparison — Vercel

Comparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores.

Summary Score

Aggregate score across all categories as reported by Unlighthouse.

Prod Desktop Prod Mobile Preview Desktop Preview Mobile
Score 90 93 92 95

Category Scores

Category Prod Desktop Prod Mobile Preview Desktop Preview Mobile
Performance 77 90 72 75
Accessibility 95 95 95 98
Best Practices 100 100 100 100
SEO 88 88 88 100

Core Web Vitals

Metric Prod Desktop Prod Mobile Preview Desktop Preview Mobile
LCP 3.5 s 3.6 s 4.3 s 4.5 s
CLS 0.001 0 0.04 0.192
FCP 1.2 s 1.2 s 1.2 s 1.2 s
TBT 0 ms 0 ms 0 ms 0 ms
Max Potential FID 40 ms 50 ms 50 ms 40 ms
Time to Interactive 3.6 s 3.6 s 4.3 s 4.5 s

Full Unlighthouse report →

@chanceaclark
chanceaclark added this pull request to the merge queue May 14, 2026
Merged via the queue into canary with commit 9aacfdc May 14, 2026
18 of 19 checks passed
@chanceaclark
chanceaclark deleted the chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display branch May 14, 2026 19:35
jorgemoya pushed a commit that referenced this pull request Jun 5, 2026
…3013)

Customer-only webpages were inaccessible and missing from navigation
when logged in. The with-routes proxy and the normal/contact webpage
page-data queries resolved routes anonymously, so the Storefront API
hid customer-restricted content from authenticated users.

- Wrap the with-routes proxy handler in auth() and thread the customer
  access token into getRoute and getRawWebPageContent
- Bypass the KV route cache when a customer access token is present;
  the cache key isn't namespaced by customer identity, so reading or
  writing it for authenticated requests could leak customer-specific
  route resolutions across users
- Pass the customer access token into normal and contact webpage
  page-data queries, switching to a no-store fetch when authenticated so
  cached anonymous responses are not served to logged-in customers
- Leave getStoreStatus unchanged (does not depend on customer identity)

Refs TRAC-293

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants