Skip to content
Documentation

Users, permissions and API

Users

Users are identified by UUID, not by name, so renaming somebody does not orphan their history. Dylaris keeps a username history with a cooldown, so a name cannot be cycled to impersonate someone.

Permissions

Permissions are per capability, not per role level. A user can be allowed to restart a server without being allowed to delete it, and allowed to read the console without being allowed to type into it.

Two things worth knowing before you hand out access:

  • Permissions are checked server-side on every request. Hiding a button in the UI is a convenience, never the control.
  • The permission to manage panel roles is effectively full administration. Someone who can edit roles can grant themselves anything, so treat it as the admin flag it really is.

API keys

A key is scoped: you pick its capabilities, you pick which servers it may touch, it carries its own rate limit and expiry, and you revoke it on its own. A key for a status page cannot restart anything.

This is what you use for a Discord bot, a monitoring check, or a deployment script. It covers ten routes under /api/external - read a server, power it, console, stats, backups, RCON, and account usage. Anything beyond those still needs a session token, which is not scoped at all, so prefer a key wherever one reaches.

Whether users other than admins may hold a key is an operator setting, off by default, and an admin can also narrow which capabilities a user key may carry.

The HTTP API

If you want to drive Dylaris from a script, read the API reference. It documents the routes an API key can call: the capability each one needs, a request you can paste into a terminal, and the JSON that comes back.

The session-only routes the panel itself calls are deliberately not published there. A session token is not a scoped credential - it is the account - so it is the wrong thing to build an integration on.

The full route table, session routes included, is generated from the source and lives in the repository as API.md. It is generated rather than written, so it cannot drift from the code: the description of a route is the doc comment on its handler.

Highlights:

  • Sessions are bearer tokens (Authorization: Bearer ...).
  • Live endpoints stream Server-Sent Events. Because browsers cannot set headers on an event stream, those accept a short-lived ticket in the query string instead, and only for GET.
  • Anything that changes state requires a capability. There is no endpoint that does something important because you happened to know the URL.

Two-factor authentication

Available for panel accounts. Turn it on for anything that can reach a server you care about.