32e5edbd04
## 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](https://github.com/triggerdotdev/trigger.dev/pull/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: - The `/login` loader read the flashed `auth:error` without 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 with `WHITELISTED_EMAILS` set), it stayed in the session cookie and reappeared on every later `/login` visit, making successful attempts look like failures. - The `/login/magic` action stored its validation and rate limit errors with `session.set`, which survives every later read and commit, so those errors stuck permanently. [#4215](https://github.com/triggerdotdev/trigger.dev/pull/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 `.server` modules were always stubbed out, so that change fixed nothing and is reverted here. ## Fix - `/login` reads the flashed error and commits the session when one was present, so an error renders once and clears. The `redirectTo` branch now surfaces the error too instead of leaving it in the cookie. - `/login/magic` flashes its errors instead of `set`ting 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.
15 lines
495 B
TypeScript
15 lines
495 B
TypeScript
import { env } from "~/env.server";
|
|
import { emailMatchesPattern } from "./emailPattern";
|
|
|
|
export function assertEmailAllowed(email: string) {
|
|
if (!env.WHITELISTED_EMAILS) {
|
|
return;
|
|
}
|
|
|
|
if (!emailMatchesPattern(env.WHITELISTED_EMAILS, email)) {
|
|
// Surfaced verbatim on the login page. Name the actual policy so a
|
|
// rejection on a restricted instance reads as configuration, not a bug.
|
|
throw new Error("This email address isn't allowed to sign in on this instance.");
|
|
}
|
|
}
|