Skip to content

Session provider lacks persistence across hard refreshes #263

Description

@usmanimamu17-create

The SessionProvider (src/providers/session.tsx) stores access and refresh tokens in memory and cookies. On hard refresh (Ctrl+Shift+R), memory tokens are lost and the provider attempts to re-bootstrap using only the cookie. With SameSite=Lax; Secure cookies, they may not be sent on certain fetch requests depending on browser security policies, causing the session to appear as "unauthenticated" even when valid cookies exist.

Root cause: Lines 169-177 in src/providers/session.tsx - No cookie re-hydration before request; memory tokens are null after hard refresh.

Why this is architecturally hard

  1. Hard refresh clears memory state, SameSite=Lax cookies may not be sent on certain fetch requests
  2. Backend expects httpOnly cookies but frontend stores tokens in memory for Axios interceptor
  3. clearTokens() called on any 401, but bootstrap failures not distinguished from session revocation

Proposed design

Add a dedicated /auth/session endpoint check before /auth/me that explicitly reads httpOnly cookies. Set localStorage flag on successful login to prevent premature logout broadcasts.

Downstream impact

Backend may need new /auth/session endpoint that reads httpOnly cookies directly.

Acceptance criteria

  • Hard refresh preserves authenticated session when valid httpOnly cookies exist
  • Bootstrap distinguishes between "no session" and "network error"
  • Test simulates hard refresh and verifies session persistence

Getting started

Files: src/providers/session.tsx, src/lib/api.ts

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third Campaignauthissue-trackingbugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions