Roles and session auth
Magic-link sessions, role gates, and what each role can do in admin and portal.
How humans authenticate
Humans never use long-lived passwords in SpeakerOps. Login issues a magic link to a known email. Completing the link creates a server-side session and sets the speakerops_session cookie with HttpOnly, Secure, and SameSite=Lax flags. Auth material must never be stored in localStorage or sessionStorage.
Sessions expire after a bounded TTL. Operators re-request a magic link when the session ends. On demo and dogfood hosts, login is membership-aware: only existing users and provisioned members are issued links, and unknown emails cannot self-register. Competition judges instead enter through /judge with an access code, which mints a shared demo-persona session lasting about four hours.
- Open /login and enter the email of an existing user or provisioned member.
- Submit the request. The Worker enqueues auth.magic_link work instead of calling the email provider on the request path.
- Open the single-use link from email. The Worker exchanges the token and sets the session cookie.
- Navigate admin or portal routes; each API call is authorized from the session on the Worker.
Roles you will see
Roles gate which UI chrome and API commands succeed. Typical roles include admin, evaluator, and speaker (portal). Admin can manage forms, decisions, schedule, design, keys, and settings. Evaluators score assigned submissions. Speakers complete portal tasks for their participation.
Authorization checks run on the Worker for every mutation. A hidden button in the SPA is not a security boundary. Agents use Bearer API keys with scopes instead of human sessions; see CLI and keys.
| Role | Primary surfaces | Typical actions |
|---|---|---|
| admin | Full /admin tree | Forms, decisions, schedule, comms, settings, API keys |
| evaluator | Evaluation /eval and related | Score submissions; no key admin or high-risk sends by default |
| speaker | Speaker portal | View tasks, complete work, upload allowed files |
Session security rules operators must keep
Do not share magic links in chat channels that retain history longer than needed. Do not paste full session cookies into tickets. Prefer provisioning a second member email over sharing one operator session. High-risk automation should use scoped API keys, not a stolen browser cookie.
Troubleshooting access
If login fails, verify that your email belongs to an existing user or provisioned member with the right role, check magic-link limits, confirm email delivery, and ensure you open the latest link only once. After role changes, sign out and request a fresh link so the session reflects the new role. Judges who see 404 on /judge are on a host where judge access is disabled.