Who can see what, in the code

Tesria’s permissions come in two layers: what someone may do on the instance at all, and what they may do in each space. Every check goes through one permission service, whether the request came from the browser, the REST API, an assistant through MCP, live content on a page, search or an export.

On the instance

Each person has a role (Owner, Administrator, User, or one an administrator made), and a role is a set of named rights, such as create spaces, use API tokens or see the user list. Every administration request names the right it needs. See Roles.

In a space

• Open until closed. A space with no permissions set can be read and edited by everyone signed in. Once any permission is set, only the people and groups it names get in.

• Three levels: view, edit and administer, each including the ones before it.

• Page restrictions narrow a page further, to named people or groups, for viewing or for editing, and apply to every page under it too. The space’s administrators can always reach every page, so a space can always be looked after.

• Anonymous readers are a separate, deliberately weak principal: they see a space only if the whole wiki allows public spaces and that space has been published.

Rules that hold everywhere

• Not found, not forbidden. Something you may not see answers 404, so nobody can learn that a private page exists by guessing its address.

• A token is its owner. An API token carries exactly its owner’s permissions, or fewer if it is read-only, and never more. An export’s render token is narrower still: one page or one space, for fifteen minutes.

• Lists are filtered, not trimmed. Search, notifications, live content and the admin screens leave out what the person looking may not see, rather than showing it and hiding the link.