Security Panel
The Security panel manages who can log into the server, with which permissions, and which automated clients have API tokens. It is the UI front-end of the ArcadeDB security model — see Users, Groups and Security Policy for the underlying concepts.
The header has a Refresh button. The panel is split into three sub-tabs.
Users
Lists every user known to the server: username, e-mail, and the groups they belong to in each database.
-
Create User — open the Create User modal.
-
Per-row actions: Edit, Delete.
The Create User modal asks for:
-
Username and Password.
-
Database Access — a table mapping each database to a group. The wildcard
row represents the default group used for any database not listed. Use the *Add Database dropdown to grant access to additional databases with a specific group.
User Groups
Groups (aka roles) bundle the permissions granted to the users that belong to them.
-
Database filter at the top — limit the table to groups defined for a specific database.
-
Create Group — open the Create Group modal.
-
Table columns: Name, Result Set Limit, Read Timeout, type-level CRUD checkboxes, database-level permission checkboxes.
The Create / Edit Group modal exposes:
-
Database and Name.
-
Result Set Limit — cap the number of rows returned per query.
-
Read Timeout — cap on the duration of read queries (ms).
-
Type Permissions — per-type Create, Read, Update, Delete checkboxes. The
row is the default applied to types not explicitly listed; use the *Add Type dropdown to override the default for specific types. -
Database Permissions — Schema Changes, Database Settings, Security.
API Tokens
Long-lived bearer tokens you can issue to scripts and services in place of username/password authentication.
-
Create Token — open the Create Token modal.
-
Table columns: Name, Database, Expiration, Status (Active / Expired), Actions (View / Revoke).
The Create Token modal asks for:
-
Name and Database.
-
Expiration date.
-
Type Permissions and Database Permissions — same structure as the Groups modal.
When you submit the form the new token is shown once in the Token Created modal, with a Copy button. The token is not shown again, so copy and store it before closing the dialog.
An expired token authenticates nobody from the moment it expires, but it stays in the list, marked as expired, until the next token is created or revoked - that is when expired entries are cleared out. You can reuse the name of an expired token for its replacement. (Since v26.10.1: an expired token disappeared at the next server restart instead, which in a cluster made the nodes disagree about the token set and could block further token administration on the node that dropped it first.)
Group and Token Changes During a Rolling Upgrade
On a cluster, a group or API-token change is replicated to every node, and the leader refuses it while any node cannot yet understand it — including a node that is simply unreachable. Nothing is submitted when it is refused, so nothing changes anywhere and the same request succeeds unaltered once the cluster is whole again.
Since 26.10.1 Studio shows this before you act instead of after: Create Group and Create Token are disabled while the cluster is not ready, with a notice above the table naming the nodes that are holding it back and why. The Create / Edit Group dialog carries the same notice, because editing an existing group is replicated the same way. Revoking a token is refused by the same rule — the control stays available, and the refusal explains itself.
See Cluster Readiness on the Cluster panel for the same information per node. Nothing of this appears on a single server or on a fully upgraded cluster.