Skip to main content

Security

Every request to a generated application's data passes three independent checks after authentication. The checks are made on the server, so they hold whichever client sends the request.

The three gates​

  1. Data access (sys_access). A role reaches a table through the windows it has been granted, read-only or read-write. The master role bypasses this lookup.
  2. Operation rules (sys_operation_access). What the model's rbac entries restrict: create, read, update or delete, per table and role. No rule for a table and operation means it is unrestricted, so rules only ever narrow.
  3. Moves (sys_workflow_transitions, sys_transition_access). A status change must follow an edge the state machine draws, for everyone, including the master role. Role rules on a move apply to everyone but the master role.

Reads need read access and writes need write access. A refusal is a 403, and an undrawn move is a 400, because it is a malformed request rather than a forbidden one.

Deny when the rules cannot be read​

If a gate cannot read its rules, because of a timeout or a lost connection, the request is refused. The one exception is a database created before a rules table existed, which is matched precisely and treated as having no rules.

Accounts​

An account is a credential and an identity, written together through /api/accounts.

  • The last administrator cannot be removed. Each change checks, after applying itself, that an active administrator remains, and rolls back if not.
  • Nobody deactivates, locks or deletes their own account.
  • Disabled means disabled now. Every access check requires the grant, the role and the account to be active, so deactivating an account withdraws access even on tokens already issued.
  • Failed sign-ins do not lock accounts, so guessing passwords cannot lock the administrator out.

Administration needs the administrator​

Writes to the dictionary, roles and grants require the master role. Reads of the dictionary stay open, because the navigation is built from it and it describes data without containing any.

Audit​

Changes to audited tables are written to audit_log, where each entry stores the hash of the one before. Verification recomputes the chain and reports the first entry that does not match.

Tested without the administrator​

Most generated tests sign in as the administrator, who passes every check. Two suites do not: one sends no credentials at all, and one builds an ordinary role with its own rules. Extend them when you add a guarded route or change what a role may do.