Permissions and roles#

The system checks on every request whether that identity may perform that action on that resource.

Roles#

Role	Who
`guest`	not signed in
`registrated`	a signed-in user
`owner`	the owner of a particular record
`admin`	an administrator

The model is flat#

A missing rule means denial

There is no inheritance and no fallback. If there is no record for a given resource-and-action pair, the action is denied — administrators included, until the rule is added.

A rule key looks like:

:Api:<Module>:<Resource>:<action>

For example :Api:Eshop:Order:updateColumns.

What is public#

Around ninety rules are open to visitors who are not signed in — reading articles, pages, code lists, categories and products.

Writing always requires signing in.

Ownership#

The owner role permits nothing by itself. Ownership is verified against the database.

Ownership is never taken from the request

If you send your own user identifier in the data, the system ignores it and on insert fills the owner in from the server.

🔴 Ownership does not work on collections#

get-all, get-by and bulk deletion are always denied to an owner

You cannot say "give me my records" through a general listing. Dedicated actions exist for your own data — but many of them have no HTTP wrapper and are therefore unreachable from outside. See the CRUD pattern.

Modes#

Mode	Behaviour
`off`	no checking
`log`	evaluates and records, denies nothing
`enforce`	denies — the current state

The switch applies to the whole API at once

There is no per-module switch. Expect that permission behaviour may change across the board.

A denial#

{
  "success": false,
  "message": "Permission denied",
  "exception": null,
  "data": null,
  "code": 400
}

with HTTP status 403.

Code 400 means permission denied, not “bad request”

The numeric codes look strikingly like HTTP statuses but do not correspond to them. See Error codes.

Calls from inside the system#

The website and administration call the same resources through an internal route — without HTTP, by building the request directly. That does not bypass the permission check: both routes go through the same guard and merely have a switch of their own.

For you as an external client, one conclusion follows

Behaviour you see on the website may not be reachable through the API — not because the website skips the check, but because many actions have no HTTP wrapper. See The CRUD pattern.

The difference between the website and the API is not permissions, but which actions exist

If something the website does will not work through the API, look for a missing endpoint or a missing rule — not for a "website exception".