Skip to main content

Several people (multi-user)

One hunt can serve several people, each seeing and changing only their own applications, companies, people, files, notes, tags and settings. They share one database: every row carries its owner, and every request runs as the account it comes from (src/scope.rs scopes each statement to the account's rows, so nothing has to remember to). Turning it on keeps what's there: it becomes the first admin's.

hunt serve --tenants --admins you@example.com,other-admin@example.com \
  --access-team yourteam --access-aud <the Access application's AUD tag>
# or HUNT_TENANTS=1 HUNT_ADMINS=… HUNT_ACCESS_TEAM=… HUNT_ACCESS_AUD=…
  • Signing in is Cloudflare Access's job: it signs people in with GitHub, LinkedIn (or any login method set up there) and hands hunt a signed token, which hunt checks against the team's keys and the application's audience tag. A request that didn't come through Access can't pass for anyone. For others to ask for an account, the Access application's policy has to let them in: Include → Login Methods → GitHub and LinkedIn (anyone signed in with one), rather than your email.
  • The early access list: asking for an account is framed as joining an early access list, with no dates or promises. Someone new, signed in, sees only "Join the early access list": their name and, optionally, what brings them to hunt. Until an admin lets them in, they see that they're on the list; if they're turned down, they can join again.
  • The admin centre (/admin, for admins): the early access list, to let people in or turn them down (with a note), and every account: its status, role (make another admin), applications, when last seen, and its CLI token; disable, enable, or remove it (with everything of theirs, if chosen); and a switch for whether new people may ask for an account at all (closed, they're told the list is closed for now; accounts already here carry on). Its Debugging info has links to hand: your Cloudflare Access identity and Log out, the health check, calendar feed, backup and API, and the source and image builds. It's under Settings in the sidebar. Admins also see System resources on Stats; others don't. The admins named in HUNT_ADMINS are admins whenever hunt starts; the first is account 1.
  • The CLI signs in with an Access service token, which has no email: set its Client ID as the account's CLI token in the admin centre, and the CLI acts as that account.
  • Backups from older versions of hunt (schema 8 on) import too, in either mode. Backups are each account's own: a backup holds its rows (and only the files they use), and importing one replaces only that account's, with new ids so they can't collide with anyone else's.
  • Gmail sync is for one person's hunt only, for now.
  • Trying it out locally: make dev-tenants (or make watch) serves target/dev.db for several people, with ADMINS (by default admin@example.test) as admins. There's no Cloudflare Access, so who's asking is taken on trust (--identity-header X-Hunt-User): in a browser, open /dev/as?email=admin@example.test to be the admin, or any other email to be someone new asking for an account; /dev/as alone signs out. Never run it like this where others can reach hunt.