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

Supabase · Edge Functions · all subjects

authentication & secrets

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

Email send rate limits - built-in SMTP and custom SMTP

Endpoints that trigger email sends are at paths /auth/v1/signup, /auth/v1/recover, and /auth/v1/user. These are limited by the sum of combined requests project-wide. With the built-in email provider, the limit is auth.rate_limits.email.inbuilt_smtp_per_hour emails per hour and cannot be customized. You can only change this limit by setting up a custom SMTP provider. On /auth/v1/user, the rate limit only applies when the endpoint is called to update the user's email address.

OTP send rate limit - project-wide requests

The /auth/v1/otp endpoint for sending One-Time-Passwords is limited by the sum of combined requests project-wide. The limit defaults to auth.rate_limits.otp.requests_per_hour OTPs per hour and is customizable.

OTP and magic link send frequency limit - per user

The /auth/v1/otp endpoint has a per-user rate limit that defaults to auth.rate_limits.otp.period window before a new request is allowed to the same user. This limit is customizable.

Signup confirmation request rate limit - per user

The /auth/v1/signup endpoint for signup confirmation requests is limited per user. The limit defaults to auth.rate_limits.signup_confirmation.period window before a new request is allowed to the same user. This limit is customizable.

Password reset request rate limit - per user

The /auth/v1/recover endpoint for password reset requests is limited per user. The limit defaults to auth.rate_limits.password_reset.period window before a new request is allowed to the same user. This limit is customizable.

Verification requests rate limit - per IP address

The /auth/v1/verify endpoint is limited by IP address. The limit is auth.rate_limits.verification.requests_per_hour requests per hour with bursts up to auth.rate_limits.verification.requests_burst requests. This limit is not customizable.

Token refresh requests rate limit - per IP address

The /auth/v1/token endpoint for token refresh requests is limited by IP address. The limit is auth.rate_limits.token_refresh.requests_per_hour requests per hour with bursts up to auth.rate_limits.token_refresh.requests_burst requests. This limit is not customizable.

MFA challenge rate limit - per IP address

Creating or verifying an MFA challenge at endpoints /auth/v1/factors/:id/challenge and /auth/v1/factors/:id/verify is limited by IP address. The limit is auth.rate_limits.mfa.requests_per_hour requests per hour with bursts up to auth.rate_limits.verification.mfa requests. This limit is not customizable.

Anonymous sign-in rate limit - per IP address

Anonymous sign-ins at the /auth/v1/signup endpoint are limited by IP address. The limit is auth.rate_limits.anonymous_signin.requests_per_hour requests per hour with bursts up to auth.rate_limits.anonymous_signin.requests_burst requests. This limit is not customizable. The rate limit only applies when this endpoint is called without passing in an email or phone number in the request body.

UNAUTHORIZED_NO_AUTH_HEADER error

The UNAUTHORIZED_NO_AUTH_HEADER error occurs when the Edge Function has JWT verification enabled but the request is missing the Authorization or apikey header. Solution: Ensure you are passing a valid JWT token in the Authorization header, check that you are sending an API key in the apikey header, or consider disabling JWT verification for public endpoints.

UNAUTHORIZED_ASYMMETRIC_JWT error

The UNAUTHORIZED_ASYMMETRIC_JWT error occurs when the Edge Function has JWT verification enabled but the Authorization header contains an invalid asymmetric ES256 or RS256 token. Solution: Ensure you are passing a valid user JWT token in the Authorization header and check that your token has not expired.

UNAUTHORIZED_LEGACY_JWT error

The UNAUTHORIZED_LEGACY_JWT error occurs when the Edge Function has JWT verification enabled but the Authorization header contains an invalid legacy HS256 token. Solution: Ensure you are passing a valid legacy JWT token in the Authorization header, check that your token has not expired, and verify that the legacy JWT secret has not been revoked or disabled.

UNAUTHORIZED_UNSUPPORTED_TOKEN_ALGORITHM error

The UNAUTHORIZED_UNSUPPORTED_TOKEN_ALGORITHM error occurs when the Edge Function has JWT verification enabled but the Authorization header does not contain an ES256, RS256, or HS256 token. Solution: Ensure you are passing a valid Supabase-issued JWT token in the Authorization header.

UNAUTHORIZED_INVALID_JWT_FORMAT error

The UNAUTHORIZED_INVALID_JWT_FORMAT error occurs when the Edge Function has JWT verification enabled but the Authorization header does not follow the Bearer <JWT Token> format. Solution: Check that you are passing Bearer <JWT Token> in the Authorization header, ensure you are sending an API key in the apikey header instead of Authorization, or consider disabling JWT verification for public endpoints.

Give your agent this brain