Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Unter dem Punkt “Authorizations” in der Backend-Admin-UI kann definiert werden, welche Benutzer, Benutzerrollen und Benutzergruppen berechtigt sind auf eine Kontextkombination zu Kommentieren. Diese Einstellungen stehen ausschließlich Benutzern mit der Rolle “admin” zur Verfügung.

Initiale Konfiguration

Im Auslieferungszustand der graphomate comments sind automatisch drei Benutzerrollen angelegt: “admin”, “editor” und “viewer”. Unter dem Punkt “Authorizations” sind dazu die passenden Regeln bereits vordefiniert. Die erste Regel verbietet zunächst allen Benutzern jegliche Interaktion mit den Kommentaren, so dass die folgenden Regeln eine sogenannte Whitelist abbilden.

Die zweite Regel definiert, dass Benutzer mit der Rolle “admin” oder “editor” alle Kommentare sehen, erstellen, bearbeiten und löschen dürfen.

Als letzte Regel wird definiert, dass Benutzer mit der Rolle “viewer” alle Kommentare nur sehen dürfen.

Diese Konfigurationen können Sie natürlich beliebig für ihre Szenarien anpassen.

Autorisierung hinzufügen

Durch einen Klick auf den + ADD Button, in der Menüleiste über der Liste bestehender Autorisierungen, kann eine neue Autorisierung hinzugefügt werden. Vorab sei bereits erwähnt, dass wenn für eine Eigenschaft der Autorisierung keine Optionen ausgewählt werden, die Autorisierung für alle Ausprägungen dieser Untereinstellung gilt.
Als Sonderfall gilt hier die Einstellung der Benutzer, Benutzerrollen und Benutzergruppen. Erst wenn alle drei leer gelassen werden, gilt die Regel für alle Benutzer.

Eine Autorisierung besteht aus mehreren Untereinstellungen, welche beim Hinzufügen einer neuen Autorisierung und beim Bearbeiten einer Bestehenden konfiguriert werden können. Beim erstellen einer Autorisierung können mehrere Punkte durch Selektion ihrer Checkboxen einzeln, oder insgesamt durch die obere Checkbox neben dem Titel ausgewählt werden. Durch Klick auf die Pfeile werden sie entweder der Autorisierung zugewiesen (dann befinden sie sich auf der rechten Seite), oder wieder abgewählt (und somit wieder auf der linken Seite). In der Bearbeiten-Ansicht einer bestehenden Autorisierung können gewählte Untereinstellungen durch ein Klick auf das (error) am rechten Rand entfernt und neue durch das Dropdown-Feld hinzugefügt werden. In beiden Fällen steht eine Suche zur Verfügung.

Autorisierungseigenschaften

Name

Der frei definierbare Name der Autorisierung dient bspw. dazu die Funktionalität zusammenzufassen.

Type

Die Auswahl zwischen “Allow” und “Deny” definiert, ob durch diese Autorisierungsregel die gewählten Aktionen für eine Kontextkombination erlaubt oder verboten werden. Hierdurch lassen sich durch Kombination Regeln nach dem Schema “alles außer” und “ausschließlich für” definieren.

Actions

Die Aktionen, die bezogen auf Kommentare ausgeführt werden können, sind in vier Freigaben unterteilt:

  1. “view”: Benutzer, die dafür freigeben sind, können bestehende Kommentare lesen.

  2. “create”: Ermöglicht Benutzern, neue Kommentare anzulegen.

  3. “edit”: Bereits bestehende Kommentare können bearbeitet werden.

  4. “delete”: Kommentare dürfen gelöscht werden.

Werden keine Aktionen ausgewählt, so gilt diese Freigabe für alle Aktionen. Der Unterschied dazu, alle Aktionen auszuwählen liegt darin, dass ohne eine Auswahl, Aktionen, die in späteren Versionen hinzugefügt werden könnten, auch direkt freigegeben sind.

Contexts

In diesem Bereich wird definiert, für welche Kontextkombination die Autorisierung angewendet werden soll. Die Darstellung beginnt mit einem “env” für EnvironmentContext oder einem “dat” für DataContext. Darauf folgt vor dem “=” der key des Kontexts und dahinter der value.

Kontexte, die hier ausgewählt werden, gelten grundsätzlich auch für spezifischere Kontextkombinationen. Das bedeutet, dass sobald ein Kommentar mindestens die gewählten Kontexte enthält, die Regel dafür greift. Nehmen wir also bspw. an, ein Benutzer ist für die Kontextkombination “Region=Central” und “Country=Germany” freigeben, so kann dieser auf Kommentaren für die Kontextkombination Central+Germany und “Year=2017” zugreifen. Dadurch untersagt ist der Zugriff hingegen für einen Kommentar der bspw. für Central+Austria gilt.

Werden keine Kontexte ausgewählt, so gilt die Regel für alle Kommentare.

Wildcard-Contexts

Ein Sonderfall bilden die sogenannten “Wildcard-Contexts”. Durch diese ist es möglich eine Autorisierung anzulegen die für alle Kontextausprägungen basierend auf dem key und unabhängig vom Wert oder andersherum gelten. Dafür muss vorab im Menüpunkt “Contexts” ein entsprechender Kontext angelegt werden, dem dann der Wert für key oder value fehlt. Dieser kann dann in Autorisierung verwendet werden.

Users

Einzelbenutzer, für die eine Autorisierung greift, können hier ausgewählt werden.

Wird kein Benutzer, keine Benutzerrolle und keine Benutzergruppe ausgewählt, so gilt diese Regel für alle Benutzer.

Roles

Die Autorisierung kann hier allen Usern in einer oder mehreren Benutzerrollen zugeordnet werden.

Groups

Analog zu den “Roles” können hier ganze Benutzergruppen ausgewählt werden.

Reihenfolge

In der Spalte “Order” auf der Übersichtsseite der Autorisierungen kann durch Klick auf die Pfeile die Reihenfolge der Regeln geändert werden. Die Regeln werden sequenziell, beginnend mit dem niedrigsten Index, abgearbeitet. Das Bedeutet, dass, wenn wie in der initialen Konfiguration zunächst ein Verbot für alles definiert wird, dieses Verbot durch einzelne Regeln mit einem höheren Index wieder abgeschwächt werden kann. Die Textuell verfasste initiale Konfiguration lautet also:

Verbiete zunächst allen Benutzern jegliche Interaktion mit Kommentaren. Erlaube jedoch “view”, “create”, “edit” und “delete” für Benutzer mit der Rolle “admin” oder “editor”. Im letzten Schritt erlaube das Ansehen von Kommentaren für Benutzer mit der Rolle “viewer” das Betrachten von jeglichen Kommentaren.

Noch ein hypothetisches Beispiel: Würde am Ende der Liste von Autorisierungen mit der höchsten Order eine Regel stehen, die alles verbietet, so wäre alle vorherigen Freigaben nichtig.

  • No labels