Authentication and CSRF

The app currently uses a server-side session cookie, not a bearer/JWT token. The API host sets a host-only HttpOnly SameSite=Lax cookie named dt_session. The browser sends it with requests using credentials: 'include'.

Session flow

1. GET /v1/auth/me establishes/checks the session and returns csrfToken. An anonymous response has user: null.
2. Send that value as X-CSRF-Token on POST requests, including login and registration. Keep the session cookie too.
3. Login/registration rotate the session and CSRF token. Use the newly returned token afterward.
4. GET /v1/auth/me returns current account capabilities and workspace metadata for signed-in users.
5. Logout destroys the session and expires its cookie.

Email changes can also rotate the session/CSRF token. Sessions have a one-hour idle lifetime and an eight-hour absolute lifetime. Membership expiry is independent of login-session expiry.

Postman and curl

Postman can retain the session cookie in its cookie jar. First request /v1/auth/me, copy its CSRF value, and include that header for POST requests. A login response supplies the next token. No Authorization Bearer header is required.

A read-only session check:

curl --cookie-jar /tmp/dynamic-tables-session.cookies \
  https://api.dynamic-tables.com/v1/auth/me

For login, use your API client's password field and cookie handling; avoid putting passwords into shared command examples, logs, or documentation.

Origins and the docs site

The API permits browser requests from the configured app origin. This docs site is not added to that allowlist and contains no live request console.

API access requires HTTPS and secure cookies. General third-party token authentication is not implemented by this session API.