Permissions and roles
What is this about?
In short: who may see or change something in a project depends on their relationship to the project, and every request is checked centrally. Projects are separated from each other, and user management admins do not see book contents. Authorized people can still copy content, though.
Protection goal
Each person should see and do only what they are authorized to in the respective project, and nothing in projects they are not part of.
How it works
Three things are kept apart and not mixed:
- The role in the project: owner, co-author or guest. There is no global author or guest role; it results from the relationship between account and project. One account can be the owner of its own projects and a guest in others.
- User management: user management admins manage accounts, but this does not give them access to book contents.
- The right to create projects: guest accounts cannot create projects of their own.
Guests come in three levels: read only, read and comment (beta reader), and editing access for publishers and editors. Editing access is not an extension of the comment level but a level of its own: it applies to one book only, only the owner can grant it, and it allows suggested changes in the text and the export of the shared book.
Measures
- We check every request centrally with fixed rules rather than with individual ad-hoc checks in the code. A test makes sure that no route is left without a check.
- In addition, a filter in the database query limits every query to the projects an account has access to. A new table that belongs to a project cannot forget this filter.
- Responses contain only fields that are explicitly released. Embedded person details contain only the identifier and display name.
- A share is checked live on every request. If it expires or you withdraw it, this takes effect on the next call.
- If you switch off a module, shares on content from that module are switched off too and take effect again when you switch it back on.
- Blocked accounts lose access on the next request, not only at the next sign-in.
- You can see who accessed your shared content and when. Only owners and co-authors see the log, not the guests being observed.
What we do not promise
- Whoever may see content can copy or photograph it. Permissions do not protect against passing it on by authorized people.
- User management admins do not see book contents. This applies to the application itself, not to people with root access to the server.
- Backstage tools such as the to-do list, research storage or writing statistics are not part of a share.
How we check this
The rules have automated tests, which the table below names. Many of them are pattern tests that search the whole code instead of checking single cases. The related scenarios (“Compromised User”, “Cross-Tenant IDOR”, “Compromised Co-Author”, “Compromised Editor”, “Permission Escalation”) are in the monthly report.
Evidence tests
| Test | What the test proves |
|---|---|
AuthorizationCoverageTest |
Every route of the application has an explicit access decision. |
TenantFilterCoverageTest |
Every table that belongs to a project is automatically narrowed to the allowed projects. |
SerializerGroupLeakageTest |
Fields without explicit release end up in no response. |
IdSubstitutionCrossTenantTest |
Requests with swapped identifiers do not reach data from other projects. |
VoterUserStatusGateCoverageTest |
Every permission check takes the current account status into account. |
BookScopeLeakageTest |
Access to one book does not reach other books. |
AccessGrantRevocationTest |
A revoked access takes effect right away. |
AccessGrantEditorialPermissionEscalationTest |
A share cannot be raised to editing rights. |
AccessLogVisibilityTest |
Only owners and co-authors see the access log. |
UserLegalDataVisibilityVoterTest |
Even a user management admin does not see the legal data of another account. |
Change history
- : First version.