3.3.1

AuthEndpoints

Email-code verify no longer returns 500 when sign-up CreateAsync throws DbUpdateException. A concurrent register can win the unique index, and a host TUser can have a required column the sign-up insert does not set. Verify looks the user up by email. A user that is already there follows the existing-user path. Otherwise verify returns the generic 401 with detail Invalid or expired code.

Sign-up sets EmailConfirmed to true before CreateAsync. It does not use the email-confirmation token provider.

A duplicate sign-up that needs two-factor authentication releases the reserved attempt and does not consume the code. That matches the existing-user path.

MagicLink.LinkUri must be an absolute http or https URI and must not contain #. A rooted path is rejected. In Production the URI must be https and its origin must be in AllowedOrigins.

Issuing a code treats SQLite busy (5) and locked (6), and MySQL deadlock 1213, as conflicts, along with SQL Server 1205 and Postgres 40001 / 40P01. The store tries the insert twice. When that call throws, send tries it twice, which is up to four attempts. A conflict that remains returns the same 200 and does not send mail.

A confirmed user's existing password stays in place when verify signs that user in. An unconfirmed user still follows UnconfirmedAccounts.

Upgrading from 3.3.0

• Hosts that set MagicLink.LinkUri to a rooted path, or to a URI that already contains #, fail startup until LinkUri is an absolute http(s) URI without #.
• Sign-up no longer requires an email-confirmation token provider.
• No migration. The email-code table is unchanged.

Packages

• AuthEndpoints 3.3.1
• AuthEndpoints.External.OAuth 3.0.0-preview.5
• AuthEndpoints.OAuth.GitHub and AuthEndpoints.OAuth.Google unchanged at 3.0.0-preview.4

Links

• GitHub release
• Compare
• Sign in with an emailed code
• Email-code module