Access control in code #

This page is for application creators who make sure each user sees and does only what roles allow. The kernel checks the module function before a view runs; everything finer is your code's job (Policy functions and limitations).

Contents #

1. Who is the user?
2. Three levels of checks
3. Background work
4. Integration users
5. Recording decisions

Who is the user? #

$user = eZUser::currentUser();
if ( !$user->isRegistered() ) { /* anonymous */ }
$userID = eZUser::currentUserID();

In web requests the user comes from the session or an API credential; in scripts, cronjobs and workers it is anonymous unless the code logs one in.

Three levels of checks #

Check at every level that applies, in every entry point. A list of items must apply the same checks as one item: filter the query, do not hide rows in the template.

Background work #

• A queue job runs as the user who queued it (user_id of expqueue); check permissions as that user, as a web request would (Queues with expqueue).
• A cronjob that writes content logs in a dedicated user with a role made for it.
• Never run background work as the administrator "to be safe": it hides permission bugs and makes the audit useless.

Integration users #

For an integration (an import, an API client), create a user with a role holding only what the integration needs, limited to its subtree or section. Give it its own API key or OAuth client, so it can be revoked alone (OAuth and API keys).

Recording decisions #

Write security-relevant actions and refusals to the audit trail, with IDs and never secrets or personal content, so administrators can review them (Audit trail, Audit).

Related pages #

• Policy functions and limitations
• Security for applications
• Permission checks for many assignments
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.