feat(core): add session-sync endpoint #2108
Conversation
🦋 Changeset detectedLatest commit: 8ede6ad 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 |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
4 Skipped Deployments
|
| function loginWithSessionSync(credentials: unknown): User { | ||
| return SessionSyncCredentials.parse(credentials); | ||
| } |
There was a problem hiding this comment.
This is a little awkward... Usually you should handle the validation of the sign in here but because we are going to move in a direction where there will alway be a session, this CredentialsProvider will actually be removed and we will just update the session accordingly. We also need to handle things like the redirect and any API validation errors so it made more sense to do the validation in the route handler, rather than in the signIn function.
chanceaclark
force-pushed
the
fix/session-sync
branch
from
97e5da1 to
00b62af
Compare
| } | ||
|
|
||
| // Note: redirectTo is going to include the full url, not a partial path | ||
| return NextResponse.redirect(content.redirectTo); |
There was a problem hiding this comment.
Do I have this right:
this redirect url here will basically be the same/ do the same thing as this?
So that this API endpoint acts as a middleware between the redirect to checkout -> managed checkout redirect?
There was a problem hiding this comment.
Yeah that redirectedCheckoutUrl uses a session-sync endpoint on the Stencil side of things, which is similar to what this endpoint does.
The big thing about this approach is it allows sessions to be sync'd when we are scoping our session cookies with the _Host prefix as they are scoped to subdomains. For example a cookie wouldn't be able to be reused from example.com (www. subdomain) to checkout.example.com.
We need to follow this general approach:
- Redirect to endpoint on another/same domain, e.g.
example.com->checkout.example.com. - Response contains the updated session via the
Set-Cookieheader +Locationheader + 3xx status. - Browser consumes the
Locationheader and redirect to the correct end destination (viaredirectTo).
chanceaclark
force-pushed
the
fix/session-sync
branch
from
00b62af to
36cf5f4
Compare
| }, []); | ||
|
|
||
| useEffect(() => { | ||
| window.addEventListener('pageshow', handleBrowserBackButtonEvent); |
There was a problem hiding this comment.
Does the force reload happen on all pages when the back button is hit and bfcache is present, even if no session syncing is needed? Or does it happen only when the user clicks on the back button coming from BC checkout?
There was a problem hiding this comment.
Could we set a flag like "redirected_to_checkout" when users click the checkout button? We only reload conditionally
Then session sync provider deletes this cookie when it successfully reloads once.
There was a problem hiding this comment.
I'll need to do some digging into here – I bet I can check the referrer before doing this.
There was a problem hiding this comment.
🤞 We can use the referrer. IIRC, BC doesn't have explicit referrer policy so it'd be the default (e.g.: strict-origin-when-cross-origin). We should at least be able to retrieve the origin value and disable bfcache if the request comes from a different origin. If we can't get this working reliably, I’d much prefer to do nothing and let users refresh the page themselves.
There was a problem hiding this comment.
Dug into this a bit and yeah strict-origin-when-cross-origin is mucking the waters here. And we probably can't add a cookie to this as we'll need some sort of validation that it was the other origin who set it - I could see a security issue where a bad actor could set the cookie and trigger infinite reloads, exhausting our resources in the process.
@bookernath from engineering perspective this might more effort than it's worth - just letting users reload the page and the session will update it. I think this is the best bet :(
chanceaclark
force-pushed
the
fix/session-sync
branch
from
36cf5f4 to
8ede6ad
Compare
chanceaclark
changed the title
⚡️🏠 Lighthouse reportLighthouse ran against https://catalyst-canary-4p51rdznb-bigcommerce-platform.vercel.app 🖥️ DesktopWe ran Lighthouse against the changes on a desktop and produced this report. Here's the summary:
📱 MobileWe ran Lighthouse against the changes on a mobile and produced this report. Here's the summary:
|
What/Why?
Adds a session sync endpoint, used for when needing to sync the session between a "3rd party" session and your Catalyst session. In the case of this endpoint, we are primarily prepping for syncing across Catalyst <-> Stencil when navigating to the checkout. We still need some work to be done on the Stencil checkout piece, but this should enable the team to sync the session back and forth.
Testing
Logging in
Screen.Recording.2025-03-18.at.16.08.24.mov
Logging out
Screen.Recording.2025-03-18.at.16.10.25.mov