Session Sharing
📐 ADR: ADR-0004 — Session sharing between SFCC and Next.js (In Progress)
Why This Exists
Section titled “Why This Exists”Users navigate between SFCC pages and Next.js MFEs on the same domain. Session state must be seamless — logged in on SFCC means logged in on Next.js pages.
How It Works
Section titled “How It Works”
Because SFCC and MFEs are served from the same domain (via the CloudFront gateway), cookies set by SFCC are readable by Next.js and vice versa.
What’s Shared
Section titled “What’s Shared”| State | Where It Lives | How MFEs Access |
|---|---|---|
| Authentication | Cookies on .hema.nl / .hema.com | Read server-side (RSC) or via Web Shell |
| Cart context | SFCC Commerce API | Web Shell api-client package |
| User identity | Session cookie | Validated per request |
What MFE Developers Need to Know
Section titled “What MFE Developers Need to Know”- Don’t implement your own auth — Use the Web Shell’s session handling (
@hema/omni-web-app-shell-core) - Cart operations go through Commerce API — Use
@hema/omni-web-app-shell-api-client - Cookies are httpOnly + secure — Can’t read auth cookies from client JS; use server-side
- Cookies flow through the gateway — CloudFront passes them to your origin during SSR
- Shell header handles UI state — Cart count, user name, login/logout are all managed by Web Shell
Security
Section titled “Security”- All auth cookies:
httpOnly,secure,sameSite - Tokens validated on each request (not just trusted from cookie)
- No sensitive data in client-accessible cookies