fix(webapp): restore magic link login on the login page#4220
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📜 Recent review details⏰ Context from checks skipped due to timeout. (16)
WalkthroughThe magic link flow now uses a short-lived HTTP-only cookie to carry the submitted email to the confirmation route. The action serializes the email when authentication redirects, and the loader parses and validates it instead of reading the session. Login validation and rate-limit errors are flashed and consumed by the login loader, preventing stale messages from persisting. The email authentication strategy no longer configures the previous session email key, and the confirmation paragraph adds balanced text wrapping. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
|
Preview Deployment
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
The /login loader read the flashed auth error without committing the session, so the flash was never consumed: once any login attempt flashed an error (for example a rejected email address), it reappeared on every /login visit and made later, successful attempts look like they failed. Commit the session when an error was read, and read the error in the redirectTo branch too instead of dropping it. The /login/magic action also stored its validation and rate limit errors with session.set, which survives every later read. Switch those to session.flash so they render once and clear.
|
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…ion format Sessions written before the flash fix stored auth:error with session.set, which get() does not auto-clear. Unset it explicitly after reading so those sessions heal on their next visit instead of carrying the stale error until the cookie expires.
2 participants
Summary
Magic link login could appear completely broken: submitting your email on the login page showed a stale "This email is unauthorized" error instead of the "we've sent you a magic link" confirmation, even when the address was fine.
This PR reverts #4215 (whose diagnosis and fix turned out to be wrong) and fixes the actual bug, which was in how login errors are stored and consumed.
Root cause
Two session bugs compounded on the login page:
/loginloader read the flashedauth:errorwithout committing the session. A Remix flash is only consumed when the session is committed after the read, so once any attempt flashed an error (for example an address rejected on an instance withWHITELISTED_EMAILSset), it stayed in the session cookie and reappeared on every later/loginvisit, making successful attempts look like failures./login/magicaction stored its validation and rate limit errors withsession.set, which survives every later read and commit, so those errors stuck permanently.#4215 had instead diagnosed a server-only module leaking into the client bundle and crashing navigation. Checking the shipped images' client bundles via their sourcemaps shows
.servermodules were always stubbed out, so that change fixed nothing and is reverted here.Fix
/loginreads the flashed error and commits the session when one was present, so an error renders once and clears. TheredirectTobranch now surfaces the error too instead of leaving it in the cookie./login/magicflashes its errors instead ofsetting them.Verified end-to-end on a live preview environment: a rejected address shows the error once and a reload clears it; a valid address lands on the confirmation screen with the address named; GitHub, Google, and SSO login paths are untouched by this diff.