Rolle der Session
Wertauflöser - Kurzfassung
Zweck: Gibt die Daten der Rolle für den anwendbaren Anmeldekontext zurück.
Der Rolle der Session-Wertauflöser gibt die Daten der Rolle (s. Rollen) für den anwendbaren Anmeldekontext zurück.
Dabei sind Laufzeit folgende Szenarien zu unterscheiden:
|
Laufzeit-Szenario |
Rückgabewert von "Rolle der Session" |
|
Der anwendbare Anmeldekontext geht direkt auf eine interaktiv oder per Login API authentifizierte Sitzung zurück. |
"Klon" der Rolle, mit der die Sitzung gestartet wurde. ►WICHTIG◄ Das Feld flatPermissionNames, das üblicherweise eine String-Liste mit den Berechtigungen der Rolle enthält, liefert in diesem "Klon" per Definition immer den Wert null. |
|
Im unmittelbaren oder mittelbaren Ausführungskontext des Wertauflösers spezifiziert eine Ausführen als-Ereignisaktion eine "Als Rolle", um den anwendbaren Anmeldekontext temporär abweichend von der tatsächlich angemeldeten Rolle zu definieren. |
Serverseitiger Datenstand der Rolle, die im temporären Anmeldekontext definiert ist. (inkl. flatPermissionNames) |
►WARNUNG◄ Rückgabewert nicht für Schreibzugriffe verwenden!
Zu Beginn einer interaktiven Sitzung wird ein Klon bzw. "Schnappschuss" von den Daten der verwendeten Rolle erstellt, damit deren Daten während der Sitzung nicht immer wieder vom Server abgerufen werden müssen. Da für die innerhalb einer Sitzung verwendete Rolle keine Schreibzugriffe durch den Benutzer dieser Sitzung nicht zulässig sind, wird der erstellte "Schnappschuss" während der Sitzung nicht erneuert. Der Rolle der Session-Wertauflöser liefert im ersten der oben beschriebenen Szenarien die Daten dieses Rollen-Klons.
ACHTUNG
Der Klon einer Rolle sollte niemals verwendet werden, um daran vorgenommene Änderungen zu speichern. Einerseits entspricht er nicht dem aktuellen serverseitigen Stand, falls dort nach dem Klonen Änderungen aus andren Sitzungen bzw. Anmeldekontexten eingegangen sind. Viel wichtiger ist aber die Einschränkung, dass im Klon die Informationen zu den Berechtigungen der Rolle (im Feld flatPermissionNames, s. o.) komplett fehlen.
Falls der Klon einer bestehenden Rolle - z. B. per Änderungen später speichern in einer Ereignisbehandlung - gespeichert werden sollte, verfügt diese Rolle danach über keinerlei Berechtigungen mehr.
Für automatisierte Schreibzugriffe sollte daher grundsätzlich der aktuelle Stand der Rolle vom Server abgerufen werden. Dazu kann die "ID" (id) des als Rolle der Session identifizierten Kontos an den Eingabeobjekt (Typsicher)-Wertauflöser übergeben werden.
Konfiguration
Der Wertauflöser ignoriert den Eingabewert und verwendet keine Parameter.
Beispiel
Beispiel: Einfaches Zuordnungskriterium
Viele Zuordnungskriterien, die inhaltlich auf die Rolle der Session abzielen, können mit einer Rollenregel - also ohne den Rolle der Session-Wertauflöser - einfach und transparent realisiert werden.
Der Rolle der Session-Wertauflöser wird dagegen benötigt, um - z. B. in einer Objekt-Feld-Regel - auf Informationen aus dem Datenmodell der Rolle zuzugreifen.
Als einfaches Anwendungsszenario soll ein Zuordnungskriterium definiert werden, das "anschlägt" falls die im Anmeldekontext verwendete Rolle vor Kurzem (in den letzten 7 Tagen) geändert wurde. Trifft dieses Zuordnungskriterium zu, kann z. B. ein Portal in der Menüleiste angeboten werden, mit dem sich der Benutzer über Änderungen an seiner Rolle informieren kann.
Konfiguration:
|
Ein Zuordnungskriterium wird wie rechts abgebildet konfiguriert:
►WICHTIG◄ Das Zuordnungskriterium berücksichtigt den "Klon" der Rolle, der beim Anmelden erstellt wird. Erfolgt eine Änderung an der Rolle während der Laufzeit einer Sitzung - also nachdem dieser Klon erstellt wurde - dann reagiert das Zuordnungskriterium erst beim erneuten Anmelden auf das dadurch geänderte Änderungsdatum. |
|
Beispiel: Prüfen ob der Rollenkontext mit "Ausführen als" verändert ist
Den Umstand, dass der in einer interaktiven Sitzung als Rolle der Session zurückgegebene "Klon" der betreffende Rolle keine flatPermissionNames beinhaltet, soll in einer Ereignisbehandlung für eine Fallunterscheidung genutzt werden, die daran "erkennt", ob die Rolle im anwendbaren Anmeldekontext auf die Sitzung oder eine Ausführen als-Ereignisaktion im unmittelbaren oder mittelbaren Ausführungskontext zurückgeht.
Konkret soll hier in einer Benachrichtigung darauf hingewiesen werden, dass eine Rolle temporär zugewiesen wurde, selbst wenn diese mit der in der "echten" Sitzung verwendete Rolle identisch ist.
|
Innerhalb einer Wenn Dann Sonst-Ereignisaktion wird eine Objekt-Feld-Regel wie rechts abgebildet verwendet, um zu prüfen, ob das Feld flatPermissionNames für die Rolle der Session nicht den Wert null hat. ►WICHTIG◄ Für diese Prüfung ist ein Vergleich mit Kein Wert notwendig, weil der Ist leer-Matcher nicht unterscheidet, ob der Rückgabewert für das Feld flatPermissionNames wirklich null ist oder nur eine leere Liste ([]). Letzteres wäre der Fall, wenn einer Rolle keine Berechtigungen zugewiesen sind. Das ist zwar begrenzt sinnvoll, kann aber nicht ausgeschlossen werden. Die Hinweis anzeigen (Popup)-Ereignisaktion unterhalb wird nur ausgeführt, wenn die zurückgegebene Rolle Berechtigungen (oder eine leere Liste) enthält, was nur der Fall ist, wenn es sich nicht um den "Klon" aus einer echten Sitzung handelt. Geht die Rolle im anwendbaren Anmeldekontext dagegen auf die Sitzung zurück, dann sieht die Fallunterscheidung keine besonderen Maßnahmen vor. |
|
