Roles & permissions
GitHub login is used only to find out who you are. What you can do comes from two places.
Where roles come from
- Anyone who can push to the repo is always an admin. That’s checked at login against GitHub. It also covers the first run: a new repo with no users file still has an admin.
- Everyone else is listed in
.trunkcms/users.yamland needs no access to the repo at all.
users:
alice-gh: { id: 1234567, role: author }
sally-foo: { id: 7654321, role: editor }
The id is filled in automatically when an admin adds someone in the UI. It stops a renamed-then-reclaimed username from inheriting a role.
What each role can do
| Capability | author | editor | admin |
|---|---|---|---|
post.create |
✓ | ✓ | ✓ |
post.edit / post.delete / draft.view |
own | all | all |
page.edit |
✓ | ✓ | |
profile.edit |
own | all | all |
asset.upload |
✓ | ✓ | ✓ |
settings.edit |
✓ | ||
users.manage |
✓ |
Every protected action goes through one policy check. The UI only shows what you can use, and every changed path is checked again when the commit is built. Hiding a button is never the only protection.
Roles are checked on every write, against the current snapshot. Removing someone takes effect on the next commit, not when their session expires.
What this protects
People in users.yaml don’t need GitHub access, so for them trunkcms is the only way in and its rules are fully enforced. Anyone with direct push access can edit anything with git, including users.yaml. That’s expected: write access on GitHub is the same as being a trunkcms admin.
Tip Keep the content repo private. In a public repo, drafts and users.yaml can be read by anyone on github.com. The admin dashboard warns you when the repo is public.
Sessions
A session is one encrypted cookie holding your login and ID, and no GitHub token. After sign-in, the OAuth token is used once to read your identity and repo permission, then thrown away. Sessions last seven days, and TRUNKCMS_SESSION_KEY accepts a comma-separated list for key rotation.