Benutzerrechte im add on nutzen#
Um das Rechtesystem im eigenen Add-on zu nutzen, muss nicht viel Logik geschrieben werden. Es ist lediglich eine "auth"-Klasse isys_auth_example mit etwas Boilerplate-Code nötig. Zusätzlich muss die Add-on-Basis Klasse das Interface "\idoit\AddOn\AuthableInterface" implementieren und die definierte Methode "getAuth" mitliefern.
Anpassung der Add-on-Basis Klasse#
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Die eigene auth-Klasse#
Die im oberen Beispiel genannte Klasse isys_auth_example muss folgendermaßen aussehen, damit i-doit diese verwenden kann:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
|
Die wichtigste Methode dieser Klasse lautet "get_auth_methods" und definiert die späteren Rechte. Der übrige Code sollte möglichst komplett übernommen und nur zweckmäßig verändert werden (z.B. verwendete Konstanten).
Autoloader nicht vergessen
Da es sich hier um Klassen im Legacy-Format handelt, müssen diese im Legacy-Autoloader registriert werden.
Eigene Rechte via get_auth_methods definieren#
i-doit liefert einige Standard-Rechte-Typen, die wir in der "get_auth_methods"-Methode wiederverwenden können, ohne weiteren Code schreiben zu müssen:
1 2 3 4 5 6 7 8 9 10 11 |
|
In diesem Beispiel verwenden wir den "boolean"-Typen. Dieser hat keinerlei Parameter, sondern funktioniert wie ein boolescher Wert: Das Recht ist da oder nicht.
Die übrigen Parameter übernehmen folgende Rollen:
- "title": Der hier hinterlegte String (Sprachkonstante) wird in der Rechtesystem-GUI dargestellt.
- "type": Definiert die darzustellenden Parameter innerhalb der GUI:
- boolean: Stellt keinen Parameter dar.
- object: Stellt einen Objektbrowser dar. Objekte können bei der Rechteprüfung als Parameter übergeben werden.
- object_type: Stellt einen Dialog mit allen Objekt-Typen dar. Diese können bei der Rechteprüfung als Parameter übergeben werden.
- category: Stellt einen Dialog mit allen Kategorien dar. Diese können bei der Rechteprüfung als Parameter übergeben werden.
- dialog_tables: Stellt einen Dialog mit allen Dialogfeldern dar. Diese können bei der Rechteprüfung als Parameter übergeben werden.
- custom_dialog_tables: Stellt einen Dialog mit allen benutzerdefinierten Dialogfeldern dar. Diese können bei der Rechteprüfung als Parameter übergeben werden.
- "rights": Definiert, welche Rechte für diese Definition verfügbar sind:
- isys_auth::VIEW
- isys_auth::EDIT
- isys_auth::DELETE
- isys_auth::EXECUTE
- isys_auth::ARCHIVE
- isys_auth::CREATE
- isys_auth::SUPERVISOR
- "default": Die hier hinterlegten Rechte werden als Standard vorausgewählt, wenn der Benutzer das Recht in der GUI hinzufügt
Im Code auf definierte Rechte prüfen#
Wir können im Code über zwei Wege auf definierte Rechte prüfen:
- isys_auth_example->is_allowed_to(
, ' ') Diese Methode liefert boolsches "true" oder "false" zurück und kann in Abfragen verwendet werden. - isys_auth_example->check(
, ' ') Diese Methode wird eine Exception (üblicherweise vom Typ "isys_exception_auth") werfen, sofern das Recht nicht existiert. Im Erfolgsfall wird boolesch "true" zurückgeliefert.
Der Code für unser Beispiel-Recht kann folgendermaßen aussehen:
1 2 3 4 5 |
|
Soll ein Recht unter Berücksichtigung eines Parameters geprüft werden, ist das folgendermaßen möglich:
1 2 3 4 5 |
|
Eigene Rechte-Prüfung definieren#
Mit Hilfe von etwas eigenem Code kann eine eigene Rechte-Prüfung eingebaut werden, anstatt sich auf die i-doit-interne Logik zu verlassen. Hinter dem Schlüssel eines Rechts (in unserem Beispiel "example_action") kann sich optional eine eigene Methode verstecken, die benutzt wird, um Rechte-Abfragen zu verarbeiten.
Im Kern des Rechtesystems steckt das "$m_paths"-Array. Darin befinden sich alle gespeicherten Rechte zum jeweils eingeloggten Benutzer im Kontext des Add-ons.
Das bedeutet, wenn wir ein Recht für unseren Benutzer für das Add-on isys_module_example hinterlegen, werden wir dieses Recht als Array innerhalb von "$m_paths" finden. Da wir das verfügbare Recht "example_action" mit Typ "boolean" angelegt haben, wird dieser den Parameter "empty-id" beinhalten. Geben wir "$m_paths" aus, erhalten wir etwa folgendes Ergebnis:
1 2 3 4 5 6 7 8 9 10 |
|
Um dieses Recht im Code zu prüfen, müsste die entsprechende Methode innerhalb von isys_auth_example folgendermaßen aussehen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
Durch die zugrunde liegende Architektur können eigene Rechte-Methoden zwar direkt aufgerufen werden, anstatt über "is_allowed_to()" oder "check()", doch davon raten wir unbedingt ab!