Module, Views und Zugriffskontrolle #

Diese Seite richtet sich an Ingenieure, die Seiten oder Endpunkte hinzufügen oder prüfen, ob eine Änderung vom falschen Benutzer erreicht werden kann. In Exponential werden Routing und Autorisierung zusammen deklariert: Die Definition einer View nennt die Berechtigung, die sie braucht. Die maßgeblichen Regeln stehen in Kernel-Architektur.

Inhalt #

1. Module, Views und Funktionen
2. Klassenbasierte Views
3. Rollen, Richtlinien und Einschränkungen
4. Die Prüfungen der Weiterleitungsschleife
5. Anfrageregeln
6. Regeln für eine neue View

Module, Views und Funktionen #

kernel/<module>/module.php legt $Module, $ViewList (je View: script, params, functions, default_navigation_part, ...) und $FunctionList fest (die Richtlinienfunktionen und die Einschränkungen, die jede annimmt). Die Modul-Repositorys sind settings/module.ini [ModuleSettings] ModuleRepositories[], und nur Module aus ModuleList[] sind erreichbar. Eine Erweiterung fügt Module über ExtensionRepositories[] und extension/<ext>/modules/<module>/module.php hinzu (Referenz der Moduldefinition).

Adressen werden meist nicht als Modulpfade eingegeben: Ein URL-Alias wie /About-us wird in content/view/full/58 übersetzt, bevor das Modul gefunden wird (URLs und Aliase).

Klassenbasierte Views #

Seit 6.0.15 ist der Code einer Kernel-View eine Klasse. kernel/content/view.php ist eine einzeilige Einstiegsdatei, die \Exponential\View\Kernel\Content\View::main() in kernel/private/classes/views/content/view.php aufruft, eine Unterklasse von Exponential\Runnable\ModuleView. Befehle und Cronjob-Teile folgen demselben Muster. Views als einfache Dateien laufen weiter, sodass Erweiterungen nicht umziehen müssen (Befehle, Cronjob-Teile und Modul-Views als Klassen).

Eine View-Klasse lässt sich über site.ini [RunnableSettings] Implementation[] ersetzen, und ein ganzes Kernel-Modul kann von einer Erweiterung ersetzt werden (Override von Modulen durch Erweiterungen).

Rollen, Richtlinien und Einschränkungen #

Die Einschränkungen, die eine Funktion annimmt, werden in $FunctionList des Moduls deklariert. Die Prüfungen sind eZUser::hasAccessTo( $module, $function ) und eZUser::hasAccessToView(); Templates verwenden fetch( 'user', 'has_access_to', ... ). Inhalts-Fetches wenden Leseberechtigungen in SQL über eZContentObjectTreeNode an, sodass eine Liste nie einen Knoten zeigt, den der Benutzer nicht lesen darf. Eigene Inhaltseinschränkungen sind über Handler für Einschränkungen möglich (Handler für Inhaltseinschränkungen).

Über den Zugriff entscheiden Richtlinien, nie eine Prüfung einer Benutzer- oder Gruppen-ID in Code oder Templates. Anleitung: Rollen und Richtlinien.

Die Prüfungen der Weiterleitungsschleife #

Für jede Webanfrage, der Reihe nach:

1. eZModule::accessAllowed(): Ist das Modul auf diesem Siteaccess erlaubt?
2. Die Anmeldeprüfung des Siteaccess: Hat der Benutzer user/login für diesen Siteaccess?
3. eZUser::hasAccessToView(): Hat der Benutzer die Funktionen, die die View nennt?
4. Anfrageregeln, wenn konfiguriert (unten).
5. Die View selbst kann feinere Berechtigungen prüfen (zum Beispiel canEdit() an einem Objekt).

Views in site.ini [RoleSettings] PolicyOmitList[] überspringen die Richtlinienprüfung absichtlich; jeder Eintrag dort ist ein öffentlicher Endpunkt und verdient eine Prüfung.

Anfrageregeln #

Anfrageregeln laufen nach der URL-Übersetzung und nachdem die Rollenrichtlinien die View erlaubt haben, und können erlauben, verweigern, weiterleiten, umschreiben oder protokollieren. Sie schließen die Lücke zwischen einer Seite und ihrer System-URL (/content/view/full/123 gegenüber ihrem Alias). Prüfen Sie, was die Regeln für eine beliebige Adresse entscheiden, ohne etwas zu ändern:

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

Siehe Anfrageregeln und Sicherheit von view/full.

Regeln für eine neue View #

• Sie muss in functions die Richtlinienfunktionen nennen, die sie braucht; eine View ohne sie steht jedem Benutzer offen, der die Siteaccess-Prüfung besteht.
• Sie sollte eine Unterklasse von ModuleView sein, kein einfaches Skript.
• Sie liest Eingaben über eZHTTPTool, verlässt sich bei POST-Anfragen auf die Prüfung des Formular-Tokens und rendert über eZTemplate::factory().
• Ein neues Modul sollte seine Funktion einem Installations- oder Aktualisierungsskript hinzufügen, damit vorhandene Websites sie erhalten (zum Beispiel bin/php/addexphelpreadpolicy.php für exphelp/read).

Verwandte Seiten #

• Eigene Module und Views
• Richtlinienfunktionen und Einschränkungen
• Checkliste für Sicherheitsprüfungen
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.