Start

Accounts and teams

A console account is for the people who build with dabadata: you and your team. This page is how you sign in, how long a session lasts, how to bring people into a workspace, and what is written down when anyone changes something. Your app's own users are a different thing; they have accounts of their own per project.

Three ways lead to the same account: one account per email address, whichever way you use.

Way	How it works
Email and password	Register with your email, a password and, if you like, your name. We mail a confirmation link that works for 24 hours; open it in the same browser and you are in. From then on, sign in with the password.
Email link	Type your email on the sign-in page and choose "Email me a link instead". The link works once, for 15 minutes. It works for a new address too: that makes the account (unless sign-up is a waitlist).
Google	"Continue with Google", when the server offers it. Your Google account is matched by its Google id, else by its email (and linked to that account), else a new account is made. Google's name and picture fill your profile if it is empty.

A password is 10 to 200 characters, not one character repeated, and not your email address.
A link in a mail opens a page with a button; nothing happens until you press it, so mail scanners that open links do not use them up.
Forgot your password? "Forgot password" mails a link that works for an hour. Choosing a new password signs you out everywhere else and signs you in here.
Last used. The sign-in page remembers, in this browser only, how you last signed in and with which email, and offers it as one card: Google opens that Google account directly, a password or link sign-in fills in your email. The × on the card forgets it. Nothing about it is sent to the server.
Signed in by link or Google and want a password too? Settings → Account: set one, or change it (with the current one). Changing it signs out your other sessions.

When sign-up is a waitlist

A server can close sign-up for new console accounts with DABADATA_CONSOLE_SIGNUP=waitlist, a self-hosting setting (the default is open). Then the sign-up page says "Join the beta waitlist", and an address that has no account yet is not made one when it is confirmed: it goes on the waitlist and the page says so. It gets in once the operator approves it (POST /v1/admin/waitlist/approve mails it a sign-in link) or when a workspace invites it. Existing accounts sign in as always, and your app's own users are not affected.

The first time an address is confirmed - by its confirmation link, an email link, Google or a password reset - dabadata sets up:

a workspace named after the part of your email before the @, on the Free plan, with you as its owner, and
a first project, my-first-app, from the tasks template: a tasks table with the demo's rules and the roles admin, editor and viewer, in a live and a test environment.

If you came through an invitation, you join that workspace instead and get no workspace of your own until you create one. Rename the workspace in Settings → Workspace and the project in Settings → Project.

Sessions

Signing in starts a session, kept in a cookie of the console's site.

A session lasts 30 days from its last use: using the console moves the end forward. However much you use it, it ends 90 days after you signed in, and you sign in again.
Settings → Account → Sessions lists where you are signed in - browser, IP address, when it was last used - and signs out one of them or every one but this.
Signing out, revoking a session, changing your password (your other sessions) and resetting it (all of them) also close that session's live console views at once.

Invitations and seats

Admins and the owner invite people from Members: an email address and a role (viewer, developer or admin; ownership only moves by a transfer). The mail's link works for 7 days and opens a page that says who invited you, to which workspace and with which role.

Signed in with the invited address: accept, and you are a member.
Signed in with another address: the invitation is refused (email_mismatch); sign out and accept it with the invited one.
Not signed in: accepting mails a 15-minute sign-in link to the invited address. Opening it signs you in - making the account if there was none - and joins the workspace.

Seats. Every member and every pending invitation takes a seat, and the plan has a fixed number: 1 on Free, 2 on Starter, 5 on Pro, any number on Scale. Free is just you, so invite someone from Starter up. An invitation over the plan answers 403 { "error": "plan_limit", "limit": "members" }. A seat comes back when an invitation is accepted (it becomes the member's seat), withdrawn or expires, or when someone leaves.

Inviting an address again replaces its pending invitation: the old link stops working, and it still holds one seat.
Inviting someone who is already a member answers 409 already_member.
To keep invitations from being used to send mail: at most 20 per workspace per hour, 50 per inviting person per day, and 3 per invited address per day (over: 429 rate_limited).

Roles in a team

The four roles - viewer, developer, admin, owner - and what each may do are in The console. Who may change whom:

Admins change roles and remove members, but not another admin's; the owner may.
Anyone may leave a workspace, except the owner, who transfers it first.
A removed member loses access with their next request, and their open console views of the workspace close at once.

Transferring a workspace

The owner can make another member the owner (Members, on that person). The new owner gets the plan, billing and deleting the workspace; the old owner becomes an admin. Only the new owner can give it back. There is always exactly one owner.

Deleting a workspace

The owner deletes a workspace in Settings → Workspace. All its projects stop answering at once (410 project_deleted) and its members lose access. After 7 days the projects are removed for good, and with the last of them the workspace, its members, invitations and audit log. A deleted workspace cannot be brought back from the console; a single deleted project can be restored for 7 days (Paused and deleted projects).

The audit log

Settings → Audit log (admins and the owner) lists what changed in the workspace, newest first, with who did it and when:

The workspace: created, renamed, deleted; the plan changed.
People: invited, joined, role changed, removed, left; an invitation withdrawn; ownership transferred.
Projects: created, deleted, restored; a key rotated or revoked; a secret set or deleted (its name, never its value); a definition applied (with its version, and the version a rollback went back to); allowed origins changed; a SQL write committed; an app user created, changed or deleted.

Changes made with a project's secret key are logged as secret key, and changes made by the operator as admin. Your password and your sessions are yours, not the workspace's: they are not in any audit log.

Account security

Confirm in the browser you registered in. The password (and name) you register with is kept only when the confirmation link is opened in that same browser. Opened anywhere else, or if the address is first proven another way (an email link, Google, the link in a "someone tried to register" mail), the account is confirmed and you are signed in, but without that password: set one in Settings → Account. This is on purpose. Anyone can register any address with a password of their choosing; only the person who can read the mail decides whether that password stays.
Until it is confirmed, a password does not sign in. The right password on an unconfirmed account answers "confirm your email first" (email_unverified) and sends nothing. If the confirmation mail is lost, use "Email me a link instead".
Nothing tells whether an address has an account. Registering, asking for a link and "forgot password" answer the same for known and unknown addresses; a known address gets a mail saying someone tried to register with it. A wrong email and a wrong password get the same invalid_login.
Attempts are limited. Password sign-ins: 10 per 15 minutes per address and 30 per IP address. Mailed links: 5 per hour per address and 20 per IP address. Over a limit the answer is 429 with how long to wait.
Links and passwords. Every link works once, and only its hash is stored. Mails never contain a password. Setting or resetting a password cancels every unused sign-in, confirmation and reset link of the account.
The session cookie is HttpOnly, SameSite=Lax and Secure on https, and the console sends a header with every call that another site cannot add. A write to the account routes without it is refused (403 csrf), so a page elsewhere cannot sign you in or out, or act as you.