fix: TRAC-293 Pass customer token through routes and webpages#3013
Merged
chanceaclark merged 1 commit intoMay 14, 2026
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: ee0dd8d The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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
force-pushed
the
chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display
branch
from
May 14, 2026 16:49
702e10f to
27d5c45
Compare
Contributor
Bundle Size ReportComparing against baseline from 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
force-pushed
the
chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display
branch
from
May 14, 2026 16:55
27d5c45 to
ee0dd8d
Compare
chanceaclark
marked this pull request as ready for review
May 14, 2026 17:22
Contributor
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
parthshahp
approved these changes
May 14, 2026
chanceaclark
deleted the
chancellorclark/ltrac-293-customer-only-web-pages-are-not-accessible-and-dont-display
branch
May 14, 2026 19:35
This was referenced May 14, 2026
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
core/proxies/with-routes.ts— the URL-to-entity resolution that runs on every navigation. The handler is now wrapped inauth(), andreq.auth?.user?.customerAccessTokenis threaded intogetRouteandgetRawWebPageContent. 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, andgetStoreStatusis intentionally untouched.app/[locale]/(default)/webpages/[id]/{normal,contact}/) —page-data.tsaccepts acustomerAccessTokenand switchesfetchOptionsto{ cache: 'no-store' }when authenticated (matching the product page pattern).page.tsxresolves the token viagetSessionCustomerAccessToken()ingenerateMetadataand the page component, then threads it throughgetWebPage,getWebPageBreadcrumbs,getWebPageWithSuccessContent, andgetContactFields.The
no-storeswitch 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
Setup:
Verify:
Migration
No migration required. No public API surface changed.
Refs TRAC-293