Sending users to accounts
Browser hand-off between a Dylog app and accounts using the next parameter.
Other Dylog apps never render sign-in forms. They send people to accounts and get them back.
Entry points
| Purpose | URL |
|---|---|
| Sign in | /sign-in?next=<absolute return URL> |
| Sign out | /sign-out?next=<absolute return URL> |
| Account settings | /account?next=… |
| Security settings | /account/security?next=… |
| Organization people | /organization/<slug>/people |
All relative to the accounts origin of the environment (production https://accounts.dylog.ai).
The next rule
next must be an absolute https:// URL whose origin exactly matches an entry in the environment's
RETURN_TO_ORIGINS allowlist. No wildcards, no subpaths in the allowlist, no http:// outside localhost.
Anything else silently falls back to the accounts home page, so a missing allowlist entry looks like "it
stays on accounts" rather than an error.
Internally accounts wraps the target as a same-origin /continue?to=<url> hop, because the UI library only
honours same-origin redirects. You do not need to construct /continue yourself.
Behaviour after sign-in
- Signed-out users see the sign-in card, then two-factor or passkey steps if enabled, then return to
next. - Already signed-in users are returned to
nextimmediately. - When
nextis absent, users land on their account page.
CORS
/api/auth/* answers cross-origin requests with credentials only for origins in RETURN_TO_ORIGINS.
Allowed request headers are Content-Type, Authorization and x-api-key. Same-site apps that share the
cookie do not need CORS for the UI, only for direct API calls from the browser.