fix(frontend): only redirect to /login when the session check returns 401/403#3231
Open
SubprimeHardware wants to merge 2 commits into
Open
Conversation
… 401/403 UserContext treats any auth/me error as a dead session and sets location.href='/login'. A fetch aborted by the user navigating away (or a brief proxy/network blip) rejects with no HTTP response and triggered the same redirect — the old page's JS is still running until the new document commits, so the redirect races the user's navigation and wins, yanking the browser back to the app. The session is actually valid, so /login 307s straight back to /. Redirect only when auth/me actually returns 401/403. The error field in UserHookResponse was declared string but is an AxiosError at runtime; typed correctly so the status check compiles. The two other consumers of error only check truthiness.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUserContext now redirects to ChangesSession Redirect Fix
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
7 tasks
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/context/UserContext.tsx`:
- Around line 35-37: In UserContext’s redirect guard, the current `!user`
condition still forces a login redirect before `/api/v1/auth/me` has proven the
session is invalid. Update the redirect logic in the UserContext component so
the `/login` redirect is driven only by the authenticated failure state
(sessionInvalid from a 401/403) or otherwise explicitly gate the `!user` branch
behind that result, keeping transient empty user state from triggering
navigation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f12458d0-cf6a-4e53-96a3-d6db326b43fa
📒 Files selected for processing (2)
src/context/UserContext.tsxsrc/hooks/useUser.ts
Review feedback: the !user branch could still navigate before auth/me has proven anything (first fetch in flight with a cold cache). The redirect is now driven solely by a 401/403 from the session check; unauthenticated full page loads are already redirected server-side by getInitialProps.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
If you're on any Seerr page and type a different site's URL into the address bar, Seerr sometimes cancels that navigation and drags you back to itself. I hit this regularly on iOS Safari and it took a while to work out what was actually happening.
The chain:
useUserrevalidates/api/v1/auth/meon window focus and every 30s. Tapping the address bar fires the focus revalidation; committing the navigation then aborts that fetch. The abort surfaces as an axios error with noresponse, andUserContexttreats any error as a dead session and setslocation.href = '/login'. The old page's JS keeps running until the new document commits, so that assignment races the user's navigation and wins (WebKit's slow commit makes it easy to hit). The session is actually still valid, so/loginimmediately 307s back to/— the visible result is "I typed another URL and ended up back on Seerr."The fix: only treat the session as invalid when
auth/meactually comes back 401/403. A rejection with no HTTP response (aborted fetch, offline blip, brief server restart mid-poll) no longer logs you out. Theerrorfield inUserHookResponsewas declaredstringbut is anAxiosErrorat runtime; fixed the type so the status check compiles. The other two consumers oferroronly check truthiness, so nothing else changes.Disclosure: I used Claude to help trace this (it dug the failure sequence out of my reverse-proxy logs and drafted the patch); I've reviewed the change and the analysis myself.
How Has This Been Tested?
Diagnosed from reverse-proxy access logs on my instance — one occurrence captured end to end:
I run a source build with this patch applied since 5 July and the yank has not recurred (monitored via the same access logs).
Checklist:
pnpm build(not run locally; the same two-file patch builds and runs in my production docker image)pnpm i18n:extract(n/a — no strings changed)Summary by CodeRabbit