Users, groups & ACLs
Purpose: Understand principals, group-based permissions, and how ACL evaluation works on the content tree.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Permissions underlie most "it works for me" mysteries |
| Tech leads | Governance foundation |
Model
Permissions attach to paths and are granted to principals (users/groups). Best practice is strictly group-based: users get membership, groups get ACLs.
/content/phi everyone: read (on publish via anonymous)
└── plans/ phi-plan-authors: read/modify/create
phi-plan-reviewers: + replicateKey permission verbs
| Verb | Grants |
|---|---|
| read | See nodes/properties |
| modify | Change properties |
| create/delete | Nodes below the path |
| replicate | Publish/unpublish |
| acl_read / acl_edit | See/change permissions themselves |
Evaluation: an access decision walks up from the target node; the nearest explicit allow/deny for any of the principal's groups wins; deny beats allow at equal proximity. Keep rules coarse and high in the tree — node-level one-off ACLs become unmaintainable.
Standard group pattern (generic)
| Group | Rights |
|---|---|
| site-authors | read/modify/create under the site's /content, read /content/dam |
| site-reviewers | authors + replicate |
| site-dam-authors | modify /content/dam/<site> |
| developers (non-prod) | broad read, /apps read; no prod write |
Service users
Backend code must not run as admin. Use service users with minimal ACLs, mapped to your bundle via the Service User Mapper — see Least privilege & service users for the full pattern.
Debugging permissions
- Reproduce with the affected user via impersonation (author: user admin → impersonate).
- CRXDE's Access Control tab on the node shows effective ACLs.
- "Missing" content on publish is usually a read ACL not replicated or an anonymous-read gap.