v0.14.0

A server can now keep its rate limits in one of Cloudflare's jurisdictions, and Gateweave Cloud keeps
them in the EU. There is no migration in this release, and the signing algorithm doesn't change.

New

• Rate limits in a jurisdiction. Set DURABLE_OBJECT_JURISDICTION (such as eu) and the
  Durable Objects that count tries at sign-in, sign-up codes and emails are kept in that
  jurisdiction. They are named by hashes of addresses, which are still personal data. Counts start
  again there once. The self-hosting guide now says how to keep each part of ID, the database, the
  logout queue and the rate limits, in one jurisdiction.
  (#115)

Gateweave Cloud

• Rate limits in the EU. id.gateweave.com sets DURABLE_OBJECT_JURISDICTION to eu, like its
  database and queue since 0.13.1. Staging does too.

If you run your own

• Nothing to do unless you want a jurisdiction. Without the setting, the rate limits stay where
  they are.

v0.13.1

Gateweave Cloud's ID now keeps its data in the EU. Nothing changes for a server you run yourself:
there is no migration in this release, and the signing algorithm doesn't change.

Gateweave Cloud

• Data in the EU. id.gateweave.com's database and its queue of logouts moved to ones created
  with Cloudflare's eu jurisdiction, which guarantees where they run and store data. The old
  database was in Eastern North America. Accounts, sessions, passkeys, apps and signing keys were
  copied over, including what was written while the release deployed. Staging moved first.
  (#112, #113)

If you run your own

• Nothing to do for this release. The top level of wrangler.jsonc, which is what you deploy,
  is as it was. Only the cloud and staging environments changed. A D1 database stays where it was
  made; the self-hosting guide says how to choose before your first deploy.
• AGENTS.md says what the Worker's cron and LOGOUTS queue do.
  (#111)

v0.13.0

A server that takes accounts by invitation can now also let in a list of addresses and domains its
owner keeps. This release has two migrations, and the signing algorithm doesn't change.

New

• The owner's list. While sign-up is closed, invitations used to be the only way in. On /server,
  the owner can now keep a list of addresses (ada@example.com) and domains (@example.com). Anyone on
  it can make an account without an invitation. A domain covers addresses at exactly that domain, not
  its subdomains. Each entry can have a note, and the list shows whether an account with that address,
  or at that domain, exists yet. It has a search and holds up to 5,000 entries. Adding and removing
  entries asks for a recent sign-in, and the activity log records each change without the address.
  Sign-up codes, GitHub, invitations and the database all follow the same rule, and an address that
  isn't allowed gets the same refusal everywhere. (#108)
• Ask for access. If SIGN_UP_REQUEST_URL is set to an https address, the sign-in and sign-up
  pages link to it as "Ask for access" while sign-up is closed. Gateweave Cloud points it at its
  waitlist. (#108)

If you run your own

• Nothing changes unless you change it. The list does nothing while sign-up is open, and
  SIGN_UP_REQUEST_URL is optional. Deploying applies migrations 0017 and 0018.
• The list holds addresses of people who may not have an account yet. The self-hosting guide says
  so, for your own privacy notice. (#108)
• Dependencies: Better Auth 1.7.18 and twelve other updates.
  (#104, #105,
  #107) drizzle-kit's copy of esbuild moved off a flagged
  version; it never reached a deployed Worker. (#101)

v0.12.0

The owner of a server with no email can now help someone back in. There is no migration in this release, and the signing algorithm doesn't change.

New

• Help someone back in. A server with no email has no password reset, and its owner could only delete the account and invite the person again. Help someone back in on /server now makes a link for choosing a new password, which the owner passes on as they do an invitation. It works once, for 24 hours, and making another replaces it. Using it signs the person out everywhere and leaves two-factor sign-in on, and their activity shows that the owner made it. It asks for the owner's password and a sign-in from the last day. On a server that sends email, it isn't there, so Gateweave Cloud has no such thing. (#99)

If you run your own

• Nothing to do for this release. Nothing changes on a server that sends email.
• If you are the owner and locked out, the self-hosting guide gives one statement that makes the same link for you, with no address to type. (#99)
• CONTRIBUTING.md now says where a newcomer can start. (#98)

v0.11.4

People now hear by email when the tries at their password run out. There is no migration in this release, and the signing algorithm doesn't change.

Security

• An email when the tries at a password run out. Whoever holds a copy of a session can use up the person's allowance, which keeps them from changing their password or two-factor on their account page for a while. They now get an email at the first refusal, saying what happened and what to do, at most once a day and only at an address they have verified. The refusal doesn't wait for it, and it is the same as before. (#94)

If you run your own

• Nothing to do for this release. With no email set up, nothing changes.
• The self-hosting guide now says where your database lives and how to choose. A D1 database stays where it was made, so this is worth reading before your first deploy. (#93)

v0.11.3

Reading a session takes one trip to the database instead of two. There is no migration in this release, and no change of signing algorithm.

Performance

• One query fewer each time a session is read. Better Auth read the session, then the person, as two queries, and each is a trip to D1's primary from wherever the Worker runs: measured at about 19 ms from Frankfurt, 109 from Virginia, 240 from Tokyo and 290 from Sydney with the primary in Eastern Europe. (#91)

If you run your own

• Where your database lives matters more than this does. A D1 database stays where it was created, and every read and write of a session goes there. Nothing to do for this release, but if your people are far from it, that is where the time goes.

v0.11.2

The account page can now end every session at once, this browser's too. There is no migration in this release, and no change of signing algorithm.

Security

• "Sign out everywhere" on the account page. "Sign out everywhere else" keeps this browser's session, so a stolen copy of this browser's cookie goes on working, and nobody can tell which of their sessions was copied. The new button asks for no password and ends every session, then says so with the way back to sign-in. Apps you signed in to are told, as they are for any other session that ends. The activity list says "Signed out everywhere". (#89)

If you run your own

• It takes the account back on a server without email. Whoever holds the cookie can use up the tries at the password, and without email there is no reset to go to. Signing out everywhere asks for no password, and signing in is not limited by those tries.

v0.11.1

Tries at a password are now held per person where a session asks for one, and each wrong one shows on the account page. There is no migration in this release, and no change of signing algorithm.

Security

• A stolen cookie could guess at the password from as many addresses as it could be sent from. Better Auth counts per client address, at five tries a minute. The six paths where a session shows a password now also share an allowance per person: 10 at once, refilling over an hour, within 30 that refill over a day. Over it, they answer 429 with the code TOO_MANY_PASSWORD_TRIES. It is spent before the password is checked, so the right password counts too and is refused once it has gone. (#87)
• The account page now shows a wrong password entered while signed in. Each one writes a password_refused row to the audit log. (#87)
• An upgrade can no longer open a route unnoticed. A test lists every Better Auth route that answers, and a new one fails until someone decides whether it stays open. (#86)

If you run your own

• Nobody can lock a person out with their address alone. Only a request with a session for that account spends the allowance, and signing in is not part of it. Whoever holds the cookie can spend it, which keeps the person from changing their password on the account page for a while. A password reset asks for no session, and the account page can end the other sessions without one.

v0.11.0

Changing a password now tells the person and always ends every other session. No migration.

Security

• A password change told nobody, and the server ended other sessions only when the page asked. It now emails the person, which may be how they first hear that someone else has the password, and ends every other session whatever the request asks. Apps signed in through those sessions hear of it by back-channel logout, as they did when the page asked, so this browser signs in to them again too. (#84)
• /change-password takes five tries a minute, in place of Better Auth's three in ten seconds. (#84)

If you run your own

• A first password and a reset send no such email. The first is the next step of signing up, and a reset's own email started it. On a server without email, nothing is sent and the rest still happens.

v0.10.6

Nobody can choose the address of their own picture any more. No migration.

Security

• /update-user and a sign-up code took any picture address, which reached apps as the picture claim, where other people's browsers fetched it. That told the server at that address when they were looking and from where. ID's pages send no picture, so both now refuse one. GitHub's stays, and pictures already stored are not changed. (#82)