Uh oh!
There was an error while loading. Please reload this page.
fix: read session cookie server-side for auth-aware nav - #21
Conversation
The `current-portal-session` cookie is HttpOnly, so the client-side `document.cookie` check never saw it. Move the detection to the root layout using `cookies()` from `next/headers`, which can read HttpOnly cookies, and stamp `data-authed` on `<html>` at render time — matching the approach the old site used. The client-side script is kept solely for the demo override (`?authed=1` / `?authed=0`), which lets both states be previewed on any URL including Vercel previews where the cookie isn't present.
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryMoves the shared session-cookie check into the server-rendered root layout so HttpOnly cookies can select auth-aware navigation before paint.
Confidence Score: 4/5The PR appears safe to merge functionally, but the root-level cookie read should be reconsidered or isolated to preserve the site's static and ISR rendering behavior. The server-derived auth signal aligns with the existing CSS and hook consumers, while the only accepted concern is the non-blocking rendering and caching cost of introducing a request-bound API in the root layout. Files Needing Attention: src/app/layout.tsx Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
R[Incoming request] --> L[Root layout]
L --> C[Read HttpOnly session cookie]
C --> A[Set html data-authed]
A --> CSS[CSS selects auth UI variant]
A --> H[Client auth hook]
Q[Demo query or stored override] --> S[Pre-paint override script]
S --> A
Reviews (1): Last reviewed commit: "fix: read session cookie server-side for..." | Re-trigger Greptile |
| const cookieStore = await cookies(); | ||
| const isAuthed = !!cookieStore.get(SESSION_COOKIE)?.value; |
There was a problem hiding this comment.
Calling the request-bound cookies() API in the shared root layout prevents routes beneath it from retaining their intended static or ISR rendering behavior, adding request-time work and conflicting with pages explicitly pinned to build-time generation.
Knowledge Base Used:Site shell and shared UI
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
What
Moves the
current-portal-sessioncookie detection from a client-sidedocument.cookiecheck to a server-sidecookies()read in the root layout, matching the approach the old site used.Why
The dashboard's session cookie is
HttpOnly— JavaScript can't read it viadocument.cookie, which is why the previous PR (#16) didn't activate the auth-aware UI despite using the correct cookie name. The server-sidecookies()API fromnext/headerscan readHttpOnlycookies, so the layout now stampsdata-authed="1"ordata-authed="0"directly on<html>at render time.What changes for visitors:
current-portal-sessioncookie): sees "Open Assembly" in the header, no Free tier on pricing, CTAs say "Add app to workspace" / "Open Assembly"Changes
src/lib/auth-script.tsSESSION_COOKIEcomment to document that the cookie is HttpOnly and read server-sideAUTH_INIT_SCRIPTto only handle the?authed=1|0demo override — it no longer attempts to readdocument.cookie(which couldn't see the HttpOnly cookie anyway)data-authedattribute untouchedsrc/app/layout.tsxcookiesfromnext/headerscurrent-portal-sessionand setsdata-authedon<html>server-sideScreenshots
No visual changes to any components — the
auth-only/unauth-onlyCSS mechanism, nav markup, pricing grid, andAuthLinkcomponents are all unchanged. This fix just makes the detection actually work.Testing
?authed=1to any URL to simulate signed-in,?authed=0for signed-out,?authed=clearto resetChecklist
npm run buildpassestsc --noEmit)Generated by Claude Code