DineGlobeDocs

Docs / Platform & trust / Your account & security

Your account & security

Sign-in, password rules, TOTP two-factor, one-time recovery codes, the ten-session cap and revoking sessions.

HostDoorManagerOwnerOrg adminFinanceRead-only

Every staff member — from a door worker to an organization owner — manages their account on one page: /app/account, reachable from the console header as “Account & security”. This page explains how signing in works, how to turn on two-step verification, how the recovery codes behave, and what happens to your other devices when something about your account changes. Everything here is enforced on the server: the browser only ever holds a session id and a version number, and every permission decision re-reads the live session row.

Sign in

Sign in at /app/login with your email and password. The page is titled “DineGlobe console” and says who it is for: “Sign in for venue owners, hosts and operators.”

If your account has two-step verification on, the first submit answers with a prompt and a new field appears: “Authenticator code (or a recovery code)”. Submit again with the 6-digit code from your authenticator app, or with one of your recovery codes. Each submit re-authenticates from scratch, so if the code step fails you are asked to enter your email and password again with it.

The error messages are fixed and honest:

Situation What you see
Empty fields “Enter your email and password.”
Wrong email or password “Email or password is incorrect.”
Two-step required “Your account uses two-step verification. Sign in again with your email, password and a 6-digit code (or a recovery code).”
Code did not match “That code did not match. Enter your email, password and a new 6-digit code (or a recovery code).”
Anything else “Sign-in failed. Try again.”

The generic wrong-credential message is deliberate. A failed sign-in never tells you whether the email exists, so nobody can probe the system to discover accounts. New accounts are created at /app/register; registering never signs you in — you finish on a success message with a link to continue to sign in.

Password rules

Passwords are 12 to 128 characters. There is no additional composition rule: length is the requirement, and a shorter password is refused. The registration form labels the field “Password (12–128 characters)” and the server enforces the same bound again on every submit.

Two-step verification (TOTP)

Two-step verification uses a time-based one-time password (TOTP) from an authenticator app. On /app/account, the section is called “Two-step verification”:

  1. Press Start two-step verification. The page shows a base32 secret under the label “Secret (enter it in your app)” plus the otpauth:// URI as plain text. Type the secret into your authenticator app by hand — the pilot build renders no QR image for enrollment.
  2. Enter the current 6-digit code under “6-digit code” and press Confirm. Codes from the previous or next time step are accepted so a slow entry still works, and each code can be used once.
  3. When the code confirms, the factor is active and the page immediately shows your recovery codes (next section). From then on, sign-in asks for a code: “On — sign-in asks for a 6-digit code from your authenticator app (or one of your recovery codes).”

The TOTP secret is stored encrypted at rest, never in plain text. A pending enrollment that you never confirm never locks you out — the code prompt appears only after a confirmed factor exists. Wrong or reused codes are refused with MFA_CODE_INVALID.

Your 10 recovery codes

Confirming two-step verification issues 10 one-time recovery codes. The page says exactly what matters: “Two-step verification is on. Save these recovery codes now — they are shown only once”, and repeats “Shown only once. Save them somewhere safe now.”

The rules behind that warning:

  • The codes are displayed exactly once. The server keeps only peppered hashes, so nobody — including support — can show them again.
  • A recovery code works at the sign-in code prompt in place of a 6-digit code, and consumes itself in a single atomic step. If two people somehow present the same code at the same moment, exactly one wins.
  • Using a recovery code marks the session as MFA-verified, exactly like a TOTP code does.

Store the recovery codes somewhere safe before leaving the page. If you lose both your authenticator and your recovery codes, you are locked out until the operator resets access for you.

Sessions: seven days, ten devices, revocable

A sign-in creates a server-side session that lasts 7 days. Your browser cookie carries only a session id and a version number — no permissions, no venue authority. On every request the server re-reads the session row, so a revoked, expired or stale session stops working immediately, even if the cookie is still on disk.

You can hold at most 10 active sessions. Signing in on an eleventh device revokes your oldest active sessions automatically to make room (recorded in the audit trail as a session-cap prune). Guests booking through a link are not affected by this cap.

The “Signed-in sessions” section on /app/account explains itself: “Devices holding an active console session. Revoking one signs it out immediately; this page never lists another user’s sessions.” Each row shows the device label (or “Session” when none was given), a “this device” badge on the one you are using now, and “Started {UTC timestamp} · verified with a code” or “· no code verified” depending on how it was opened.

Revoke a session, or all of them

Every non-current session row has a Sign out button. Revoking signs that device out immediately — the still-present cookie stops working on its next request. The response confirms “Session signed out.” Session ids belonging to another account read as not found, so you cannot revoke someone else’s session by guessing ids.

The Sign out button in the console header ends your current session the same way: the server revokes the session row, the cookie is cleared and you land back on the sign-in page.

Changing your password signs every device out

Each account carries an internal version number. A password change bumps that version and revokes every live session in the same atomic step, so sessions minted under the old password die instantly — including the one you changed it from. Nothing survives that is “half old, half new”: there is no window where an old session keeps working.

During the pilot there is no self-service password-change screen in the console; the account page carries two-step verification and sessions. The password change runs through the one-time reset-token flow: a single-use RESET_PASSWORD token (valid for 30 minutes) sets the new password and performs the same version bump and mass revocation. See the recovery section below for how you reach that flow today.

When a fresh code is required

Two-step verification is checked in two strengths:

  • Presence — the session was verified with a code at some point. Platform-operator commands and operations surfaces require this much.
  • Recency — the code was verified within the last 30 minutes. Every human refund action — requesting a refund and approving or declining one — demands this. If your verification is older, the action answers MFA_REQUIRED; sign in again with a fresh code and retry promptly.

The sessions list shows which of your sessions carry a code verification (“verified with a code” versus “no code verified”).

If you forget your password

The pilot sends no email at all, so there is no self-service “forgot password” screen that could mail you a reset link — building one that silently does nothing would be dishonest. The reset machinery exists (single-use 30-minute token, full session revocation on use), but during the pilot it is operated manually:

  1. Contact DineGlobe through the /support page or /contact page.
  2. An operator issues the single-use reset token through the operator tooling. The token is valid for 30 minutes and can be used once.
  3. Set a new password from the token. Every existing session on the account is revoked at that moment, and you sign in fresh.

If you have lost your second factor as well, say so in the same message — recovery is slower, but it is a human conversation with the operator, not an automated path that can be abused.