Skip to the content
Documentation
Help Start
Reading in:
  • German: 9,059 of 9,059 pages
About the help in other languages
All help pages

Modules, views and access control

How Exponential routes a request to code and decides whether the user may run it - modules, views and policy functions in module.php, class-based views, roles, policies and limitations, the access checks of the dispatch…

Download as PDF

Address: https://doc.exponential.earth/exphelp/viewer/help/software-engineers/modules-views-and-access-control.md

On this page

Modules, views and access control

This page is for engineers who add pages or endpoints, or who review whether a change can be reached by the wrong user. In Exponential, routing and authorization are declared together: the definition of a view names the permission it needs. The authoritative rules are in Kernel architecture.

Contents

  1. Modules, views and functions
  2. Class-based views
  3. Roles, policies and limitations
  4. The checks of the dispatch loop
  5. Request rules
  6. Rules for a new view

Modules, views and functions

TermMeaningExample
Modulea URL namespacecontent, user, exphelp
Viewone page or endpoint of a modulecontent/view, exphelp/viewer
Functiona permission that views requirecontent/read, exphelp/read

kernel/<module>/module.php defines $Module, $ViewList (for each view: script, params, functions, default_navigation_part, ...) and $FunctionList (the policy functions and the limitations each accepts). The module repositories are settings/module.ini [ModuleSettings] ModuleRepositories[], and only modules listed in ModuleList[] are reachable. An extension adds modules through ExtensionRepositories[] and extension/<ext>/modules/<module>/module.php (Module definition reference).

Addresses are usually not typed as module paths: a URL alias such as /About-us is translated to content/view/full/58 before the module is found (URLs and aliases).

Class-based views

Since 6.0.15 the code of a kernel view is a class. kernel/content/view.php is a one-line entry file that calls \Exponential\View\Kernel\Content\View::main() in kernel/private/classes/views/content/view.php, a subclass of Exponential\Runnable\ModuleView. Commands and cronjob parts follow the same pattern. Plain-file views still run, so extensions are not forced to move (Commands, cronjob parts and module views as classes).

A view class can be replaced through site.ini [RunnableSettings] Implementation[], and a whole kernel module can be replaced by an extension (Extension module override).

Roles, policies and limitations

ObjectClassMeaning
RoleeZRolea named set of policies
PolicyeZPolicygrants one module function, optionally limited
LimitationeZPolicyLimitation, eZPolicyLimitationValuenarrows a policy: by class, section, subtree, owner, language, state ...
Assignmenta role given to a user or a group, optionally limited to a subtree or section

The limitations a function accepts are declared in the module's $FunctionList. The checks are eZUser::hasAccessTo( $module, $function ) and eZUser::hasAccessToView(); templates use fetch( 'user', 'has_access_to', ... ). Content fetches apply read permissions in SQL through eZContentObjectTreeNode, so a list never shows a node the user may not read. Custom content limitations are possible through limitation handlers (Content limitation handlers).

Access is decided by policies, never by checking a user or group id in code or templates. Guide: Roles and policies.

The checks of the dispatch loop

For every web request, in order:

  1. eZModule::accessAllowed(): is the module allowed on this siteaccess?
  2. The siteaccess login check: does the user hold user/login for this siteaccess?
  3. eZUser::hasAccessToView(): does the user hold the functions the view names?
  4. Request rules, when configured (below).
  5. The view itself may check finer permissions (for example canEdit() on an object).

Views listed in site.ini [RoleSettings] PolicyOmitList[] skip the policy check by design; every entry there is a public endpoint and deserves review.

Request rules

Request rules run after URL translation and after the role policies allowed the view, and can allow, deny, redirect, rewrite or log. They close the gap between a page and its system URL (/content/view/full/123 against its alias). Check what the rules decide for any address without changing anything:

php bin/php/ezrequestrules.php -s site --check
php bin/php/ezrequestrules.php -s site --uri=content/view/full/2

See Request rules and View full security.

Rules for a new view

  • It must name the policy functions it needs in functions; a view without them is open to every user who passes the siteaccess check.
  • It should be a ModuleView subclass, not a plain script.
  • It reads input through eZHTTPTool, relies on the form token check for POST requests, and renders through eZTemplate::factory().
  • A new module should add its function to an installer or update script so existing sites get it (for example bin/php/addexphelpreadpolicy.php for exphelp/read).

Become an Exponential Partner

Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.

Something wrong on this page? Report an error

Documentation license

This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.

Exponential Copyright © 1998-2026 Exponential Foundation and 7x