Problem
POST /api/v1/register (and email login) currently returns a full session token immediately, even when the email address is unconfirmed — the confirmation email is queued but sign-in proceeds regardless. The only available gate is GAMEND_AUTH_REQUIRE_ACTIVATION, which requires an admin to activate each account manually.
There is no built-in way to enforce "the player must prove they own the email" before they can play.
Use case
Right now, a player who registers can immediately call the API with the returned token, without ever checking the inbox.
Proposed behavior
A new auth setting (e.g. GAMEND_AUTH_REQUIRE_CONFIRMED_EMAIL, default false). When enabled:
Registration no longer accepts a password and no longer returns tokens. POST /api/v1/register takes only the email (and optional username); it creates the account in an unconfirmed state, queues the confirmation email, and answers success without any session
The confirmation link is what activates the account. Clicking the link in the email (in the browser) confirms the address and lets the player set a password there
Password login is refused until the email is confirmed (e.g. 403 email_not_confirmed)
Magic link login already proves inbox ownership, so it would naturally confirm the email as it does today
The C++ SDK (and other game SDKs) can surface email_not_confirmed and prompt the player to check their inbox
If registration still accepted a password and returned a token right away, the whole mechanism would be pointless — a bot could register with a password and enter the game without ever confirming anything.
The client-side workaround today (check confirmed_at on GET /api/v1/me) is only a soft gate, since the token is already valid — a server-side option would make the enforcement real.
Problem
POST /api/v1/register (and email login) currently returns a full session token immediately, even when the email address is unconfirmed — the confirmation email is queued but sign-in proceeds regardless. The only available gate is GAMEND_AUTH_REQUIRE_ACTIVATION, which requires an admin to activate each account manually.
There is no built-in way to enforce "the player must prove they own the email" before they can play.
Use case
Right now, a player who registers can immediately call the API with the returned token, without ever checking the inbox.
Proposed behavior
A new auth setting (e.g. GAMEND_AUTH_REQUIRE_CONFIRMED_EMAIL, default false). When enabled:
Registration no longer accepts a password and no longer returns tokens. POST /api/v1/register takes only the email (and optional username); it creates the account in an unconfirmed state, queues the confirmation email, and answers success without any session
The confirmation link is what activates the account. Clicking the link in the email (in the browser) confirms the address and lets the player set a password there
Password login is refused until the email is confirmed (e.g. 403 email_not_confirmed)
Magic link login already proves inbox ownership, so it would naturally confirm the email as it does today
The C++ SDK (and other game SDKs) can surface email_not_confirmed and prompt the player to check their inbox
If registration still accepted a password and returned a token right away, the whole mechanism would be pointless — a bot could register with a password and enter the game without ever confirming anything.
The client-side workaround today (check confirmed_at on GET /api/v1/me) is only a soft gate, since the token is already valid — a server-side option would make the enforcement real.