How does singing on client side makes user available on server side automatically in auth-helper?

I see we get user server side in nextjs by

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const supabaseServerClient = createServerSupabaseClient<Database>({ req, res })
  
const { data:{ user } } = await supabaseServerClient.auth.getUser()

}

I want to know how user is automatically available here?

1. I never set user server side while signing client side.
2. Also i never used onAuthStateChange client side
3. I never set any supabase cookies in req object sent to next js API route

[rphlmr]

One more thing, cookies are vulnerable to XSS when they are not HttpOnly 😉

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#httponly-attribute

[rphlmr]

Thanks, @hf for your detailed answer.

Before you released this package I built a solution to sync Remix session cookies with the browser’s Supabase client (mostly to use real-time). The idea was to get the session from the root loader and put it in a React Context (with an interval effect based on expires_in to trigger a Remix action and refresh the session).

I maintain a Remix stack around Supabase and Prisma and someone ask me if I could “replace” the hand-crafted thing I did, with your package. Because I previously had questions about security concerns, I wanted to be sure how It works 😇 .

I’ll consider updating my stack to not scatter people with multiple ways to handle auth in Remix with Supabase.