tinbase 0.16.2 → 0.18.0

package/dist/auth/handler.d.ts

@@ -99,6 +99,7 @@ interface UserRow {
     phone: string | null;
     phone_confirmed_at: Date | string | null;
     is_anonymous: boolean | null;
+    email_change: string | null;
 }
 /** Routes and services the GoTrue-compatible `/auth/v1/*` endpoints. */
 export declare class AuthHandler {
@@ -120,18 +121,34 @@ export declare class AuthHandler {
      * (GoTrue's `over_request_rate_limit`) when exceeded, else null to proceed.
      */
     private limit;
+    /** GoTrue's 429 for `max_frequency`, with the seconds the caller must wait. */
+    private static tooSoon;
     /**
-     * Enforce `max_frequency`: refuse a second auth email to the same address
-     * within the configured window (GoTrue's `over_email_send_rate_limit`).
+     * Enforce `max_frequency` the way GoTrue does: against the timestamp that
+     * flow last wrote on the user row, not against one budget per address.
      *
-     * Keyed by recipient, not by caller, and checked before the account is looked
-     * up. Both matter: keying by caller lets someone rotate addresses and keep
-     * mailing one victim, and checking after the lookup would answer differently
-     * for an address that exists than for one that does not - handing back the
-     * account enumeration that answering 200 for unknown addresses exists to
-     * prevent.
+     * Which column a flow measures itself by is GoTrue's mapping, quirks
+     * included - a magic link is measured by `recovery_sent_at`, the same column
+     * password recovery uses, because GoTrue mints both from the recovery token.
+     * Sharing that budget is therefore correct rather than an oversight; a
+     * confirmation, by contrast, has its own. An app that sets `max_frequency`
+     * in config.toml gets the pacing Supabase's docs describe, which is the
+     * point of spelling it the same way.
+     *
+     * An address with no account has no row to measure, so those fall back to an
+     * in-memory window keyed the same way. GoTrue simply lets them through,
+     * which makes a 429 proof that an account exists - `/recover` answers 200
+     * for an address it has never seen precisely so the response cannot be used
+     * to enumerate accounts, and a frequency check that only ever fires for real
+     * users hands that back. The fallback keeps the two indistinguishable.
      */
     private limitEmailFrequency;
+    /**
+     * Record that this flow has just mailed the address, so the next request is
+     * measured from now. Written only after the mail was accepted - a transport
+     * that refused it has not spent the window.
+     */
+    private markEmailSent;
     /** Stop background timers (rate-limiter sweep). Called on backend close. */
     stop(): void;
     /** Dispatch one `/auth/v1/*` request. Any thrown error becomes a 500 `unexpected_failure`. */
@@ -140,6 +157,33 @@ export declare class AuthHandler {
     private token;
     private getUser;
     private updateUser;
+    /**
+     * Begin an email change: park the new address, mint a token for each side,
+     * and mail them.
+     *
+     * The address does not move until the tokens come back. Writing it straight
+     * to `auth.users.email` - which is what this did - means a session is all it
+     * takes to walk an account to an address of the holder's choosing, with no
+     * confirmation from either end and nothing sent to the address losing it.
+     *
+     * With `secure_email_change_enabled` (the Supabase default) both ends have
+     * to click: the new address proves it exists and is reachable, and the
+     * current one gets a say in losing the account. The second token is what
+     * makes a stolen session insufficient on its own.
+     *
+     * Returns a Response only when the change could not be started.
+     */
+    private startEmailChange;
+    /**
+     * Park the new address and mint a token per side, without sending anything.
+     *
+     * Shared with `admin/generate_link`, which needs the same tokens but hands
+     * them to the caller. One implementation so the two cannot disagree about
+     * how many sides there are or when the previous attempt is invalidated.
+     */
+    private mintEmailChangeTokens;
+    /** One side of an email change, to whichever address that side belongs to. */
+    private mailEmailChange;
     /**
      * POST /auth/v1/logout[?scope=global|local|others]
      *
@@ -180,6 +224,21 @@ export declare class AuthHandler {
      */
     private issueToken;
     private sendOtp;
+    /**
+     * POST /auth/v1/resend - send the confirmation for `type` again.
+     *
+     * This used to be an alias for /magiclink, which is a different email
+     * entirely: it mails a login link measured by `recovery_sent_at`, creates an
+     * account for an address it has never seen, and pays no attention to `type`.
+     * So a resend for an address with no account signed that person up and sent
+     * them a way in, and a resend for a signup was paced by the recovery window.
+     *
+     * GoTrue answers 200 with an empty body both for an address it does not know
+     * and for one already confirmed - the two look identical from outside, which
+     * is what stops the endpoint from reporting who has an account. No mail goes
+     * out in either case.
+     */
+    private resend;
     private sendRecovery;
     /** Max wrong guesses for a one-time code before its tokens are invalidated. */
     private static readonly MAX_OTP_ATTEMPTS;
@@ -194,6 +253,25 @@ export declare class AuthHandler {
      * otp+magiclink rows.
      */
     private static redeemTypes;
+    /** What a caller is told when one side of an email change is still outstanding. */
+    private static readonly EMAIL_CHANGE_PENDING_MSG;
+    /**
+     * Redeem one side of an email change.
+     *
+     * Not routed through {@link redeem}, which exists for the login and recovery
+     * tokens and does things that are wrong here: it clears every live token for
+     * the address and stamps `last_sign_in_at`, and an email change is not a
+     * sign-in. It also cannot express the part that matters - that one click may
+     * not be enough.
+     *
+     * The address moves only once no side is left outstanding. With
+     * `secure_email_change_enabled` that means both tokens, in either order;
+     * with it off there is only ever the new address's. Deciding it by what
+     * remains in the table, rather than by counting clicks, is what makes the
+     * order irrelevant and a replay harmless - the row is gone the moment it is
+     * redeemed.
+     */
+    private verifyEmailChange;
     private verifyToken;
     private verifyLink;
     private admin;
@@ -212,6 +290,14 @@ export declare class AuthHandler {
      * is nothing to un-hash and `verifyOtp({ token_hash })` redeems it directly.
      */
     private generateLink;
+    /**
+     * `admin.generateLink({ type: 'email_change_current' | 'email_change_new' })`.
+     *
+     * Both sides are minted whichever is asked for - they are one change, and
+     * minting only the requested half would leave a secure change that can never
+     * complete. The caller gets the link for the side it named.
+     */
+    private generateEmailChangeLink;
     /**
      * Append a security event to auth.audit_log_entries (GoTrue-compatible
      * payload). Best-effort: a logging failure never breaks the request.