new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Better Auth · Plugins · all subjects

magic-link/configuration

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Magic link auto-signup behavior

If the user has not signed up, unless disableSignUp is set to true, the user will be signed up automatically.

Magic link token expiration

The expiresIn configuration option specifies the time in seconds after which the magic link will expire. The default value is 300 seconds (5 minutes).

Magic link allowedAttempts deprecated

The allowedAttempts configuration option is deprecated. Each verification call now consumes the token atomically on the first attempt, so retries always fail with error=INVALID_TOKEN regardless of this setting. The option is kept for source compatibility but ignored; multi-attempt redemption is no longer supported. Setting it to any value other than 1 emits a console.warn at startup.

Magic link disableSignUp configuration

The disableSignUp configuration option, when set to true, prevents users from signing up using the magic link. The default value is false.

Magic link generateToken configuration

The generateToken configuration function is called to generate a token which uniquely identifies the user. It takes one parameter: email (the email address of the user). The default value is a random cryptographically secure string. The returned string should be hard to guess because it is used to verify identity in a confidential way.

Magic link storeToken configuration options

The storeToken configuration controls how the magic link token is transformed before storage by Better Auth's verification layer. Options are: 'plain' - token stored in plain text; 'hashed' - token hashed using default hasher; {type: 'custom-hasher', hash: (token: string) => Promise<string>} - token hashed using custom hasher. The default value is 'plain'. Storage backend is controlled by global verification config; secondaryStorage can store magic link verification records elsewhere instead of database.

Magic link secondaryStorage atomic requirement

When secondaryStorage backs verification (verification.storeInDatabase: false), the atomic single-use guarantee requires secondaryStorage to expose getAndDelete (Redis GETDEL, KV getAndDelete). If implementation only exposes get and delete, the consume falls back to in-process JavaScript lock that does not coordinate across multiple application instances. Multi-instance deployments using secondary-storage verification MUST configure a backend that implements getAndDelete.

Magic link sendMagicLink callback parameters

The sendMagicLink configuration function is called when a user requests a magic link. It receives an object with: email (the email address of the user), url (the URL to be sent to user, containing the token), token (the token if wanting to send with custom URL), metadata (additional request metadata passed from signIn.magicLink). It also receives a ctx context object as the second parameter.

Give your agent this brain