Einschränkung von Daten je nach Berechtigungen oder im Sitzungsspeicher gespeicherten Informationen

In der modernen Anwendungsentwicklung sind die Sicherung und die präzise Verwaltung des Datenzugriffs unerlässlich. Dank des Restrict-Ereignisses in 4D ist es möglich, die für einen Benutzer zugänglichen Daten dynamisch zu filtern, basierend auf seinem Profil, seinen Privilegien und den in der Sitzung gespeicherten Informationen.

In diesem Blog wird erläutert, wie dieses Ereignis insbesondere im Rahmen einer Integration mit 4D Qodly Pro genutzt werden kann, um sicherzustellen, dass nur relevante Daten zugänglich sind.

Performance Review Application

Das restrict-Ereignis verstehen

Das restrict Event ist ein automatischer Filtermechanismus, der auf die Entitäten einer Datenklasse in ORDA angewendet wird. Er wird ausgelöst, um Abfrageergebnisse (all(), query(), API REST-Zugriff usw.) auf der Grundlage eines bestimmten Kontexts (Benutzerinformationen, Berechtigungen usw.) einzuschränken.

Wichtigste Vorteile:

• Dynamische Filterung: Jedes Mal, wenn eine Abfrage ausgeführt wird, wird der von restrict definierte Filter automatisch angewendet.
• Granulare Zugriffskontrolle: Der Zugriff kann vollständig eingeschränkt oder auf bestimmte Datensätze beschränkt werden, basierend auf Benutzerrollen, Berechtigungen oder kontextbezogenen Daten wie geografischer Standort oder Abteilung.
• Getrennte Logik: Die Implementierung dieser Filterung ist unabhängig von der Geschäftslogik der Anwendung, was die Wartung und Sicherheitsaktualisierung erleichtert.

Weitere Details finden Sie in der offiziellen 4D Dokumentation zu Entity Filtering, die einen umfassenden Überblick über diese Funktion bietet.

Privileg vs. Einschränkung: Die Hauptunterschiede

In 4D wird die Zugriffskontrolle über Privilegien und Beschränkungen verwaltet, die zusammenarbeiten, um einen sicheren und granularen Datenzugriff zu gewährleisten. Das Verständnis des Unterschieds zwischen diesen beiden Mechanismen ist entscheidend für die Entwicklung eines robusten Sicherheitsmodells.

Privilegien: Kontrolle des Zugriffs auf Datenstrukturen

Ein Privileg bestimmt, ob ein Benutzer zum Zugriff auf eine Tabelle, ein Feld oder eine Funktion innerhalb der Datenbank berechtigt ist. Es fungiert als übergeordneter Zugriffskontrollmechanismus, der den Zugriff auf einen ganzen Datensatz oder eine Funktion gewährt oder verweigert.

Beispiel für Anwendungsfälle:

• Ein Basisbenutzer hat möglicherweise nur Lesezugriff auf die Tabelle „Mitarbeiter“, kann aber keine Datensätze bearbeiten oder löschen.
• Ein Manager kann über zusätzliche Berechtigungen verfügen, die es ihm ermöglichen, Mitarbeiterdatensätze innerhalb seiner Abteilung zu ändern.
• Einem HR-Administrator kann Zugriff auf sensible Felder wie Gehaltsinformationen gewährt werden, während normale Mitarbeiter diese Details nicht sehen können.

Restriktionen: Verfeinerung des Zugriffs auf Datensatzebene

Während Berechtigungen den Zugriff auf struktureller Ebene steuern, bestimmen Einschränkungen, welche spezifischen Datensätze innerhalb einer autorisierten Tabelle ein Benutzer sehen oder mit ihnen interagieren kann. Das Ereignis „on restrict“ filtert Daten dynamisch auf der Grundlage des Benutzerkontexts und stellt sicher, dass Benutzer nur auf relevante Datensätze zugreifen und dabei die vordefinierten Sicherheitsregeln einhalten.

Beispiel für einen Anwendungsfall:

• Ein Mitarbeiter kann nur auf seine eigenen Datensätze in der Tabelle „Mitarbeiter“ zugreifen.
• Ein Manager kann die Datensätze seiner direkten Mitarbeiter einsehen.
• Ein Personalverwalter kann alle Mitarbeiter sehen.

Anwendungsfälle

Beispiel 1: Kombination von Berechtigungen und Sitzungskontext zur Einschränkung von Daten

In diesem Beispiel implementieren wir das Ereignis restrict in der Datenklasse Employee, um die zurückgegebene Liste der Mitarbeiter zu filtern. Der folgende Code veranschaulicht, wie Sitzungsinformationen und Berechtigungen zur Bestimmung des Datenzugriffs verwendet werden können:

Function event restrict() : cs.EmployeeSelection
var $obj : Object
If (Session=Null)
  $obj:=Storage
Else
  $obj:=Session.storage
End if
Case of
  : (Session.hasPrivilege("authentify"))
   return This.all()
  : (Session.hasPrivilege("generatePDF"))
   return This.all()
  : (Session.hasPrivilege("createReview"))
   return This.all()
  : (Session.hasPrivilege("webadmin"))
   return This.all()
  : ($obj.Employee.role="Collaborator")
   return This.query("ID = :1"; $obj.Employee.ID)
  : ($obj.Employee.role="Manager")
   return This.query("ID_Supervisor = :1"; $obj.Employee.ID)
  : (($obj.Employee.role="HR") && (Session.hasPrivilege("hr")))
   return This.all()
  Else
   return This.newSelection()
End case

Wie es funktioniert

• Privilegienbasierte Filterung: Die Funktion hasPrivilege() prüft, ob die Sitzung des Benutzers bestimmte Berechtigungen enthält. So erhalten beispielsweise Mitarbeiter der Personalabteilung mit der Berechtigung „hr“ Zugriff auf alle Mitarbeiterdatensätze.
• Temporäre Rollenerweiterung: Für Aktionen wie Authentifizierung, Dokumentenerstellung oder Überprüfungserstellung kann die Berechtigungserweiterung vorübergehend erweiterte Rechte gewähren, ohne die globalen Einstellungen des Benutzers zu ändern.
• Sitzungsbasiertes Filtern: Die Rolleneigenschaft (entweder im Speicher oder im Sitzungsspeicher gespeichert) bestimmt die Zugriffsebenen. Mitarbeiter können nur ihre eigenen Datensätze sehen, Manager können auf unterstellte Mitarbeiter zugreifen und Personalverantwortliche können alle Mitarbeiter sehen.
• Sichere Standardrückgabe: Wenn keine Bedingungen erfüllt sind, sorgt This.newSelection() dafür, dass der Benutzer keine Daten und keinen uneingeschränkten Zugriff erhält.

Hinweis: Das Webadmin-Recht wird vom Data Explorer in 4D verwendet. Wenn Sie möchten, dass der Datenexplorer auf Ihre Daten zugreift, müssen Sie den Fall für das webadmin-Recht behandeln. In unserem Beispiel gewähren wir vollen Zugriff auf den Data Explorer, indem wir This.all() zurückgeben, wenn dieses Privileg vorhanden ist.

Beispiel 2: Integration in Qodly Studio mit Standard-Aktionen oder -Funktionen

Das zweite Beispiel zeigt, wie man den Zugriff auf Bewertungen in der Datenklasse “ Review“ basierend auf der Rolle des Benutzers einschränken kann.

Function event restrict() : cs.ReviewSelection
var $obj : Object
If (Session=Null)
  $obj:=Storage
Else
  $obj:=Session.storage
End if
If ($obj.Employee.role=Null)
  return Null
End if

Case of
  : (($obj.Employee.role="HR") && (Session.hasPrivilege("hr")))
   return This.all().orderBy("Date desc")

  : ($obj.Employee.role="Manager")
   return This.query("Employee.ID_Supervisor = :1"; $obj.Employee.ID).orderBy("Date desc")

  : ($obj.Employee.role="Collaborator")
   return This.query("ID_Employee = :1"; $obj.Employee.ID).orderBy("Date desc")

  : (Session.hasPrivilege("webadmin"))
   return This.all()

Else
  return This.newSelection()
End case

Verwendung von Standardaktionen

Auf der Mitarbeiterseite der Qodly-Anwendung hat der Benutzer die Rolle des Mitarbeiters und kann nur seine eigenen Beiträge einsehen.

In Qodly Studio definieren wir die Standardaktion All, um die Datentabelle beim Ladeereignis der Kollaborationsseite zu füllen. Normalerweise ruft die Standardaktion Alle alle Bewertungen ab. Da wir jedoch das Ereignis „restrict“ (einschränken) zu der Datenklasse „review“ hinzugefügt haben. Wir rufen nur Rezensionen ab, die mit der Rolle „Mitwirkender“ autorisiert wurden.

Verwendung benutzerdefinierter Funktionen

Auf der Seite „Manager“ können Benutzer mit der Rolle „Manager“ alle Bewertungen für ihre Untergebenen anzeigen. Wir fügen eine erweiterte Filterfunktion hinzu, um die Ergebnisse nach Jahr und Status zu filtern.

In der Datenklasse „Review“ gibt es die Funktion loadReviews:

exposed Function loadReviews($departement : cs.DepartementEntity; $year : Integer; $status : cs.ReviewStatusEntity) : cs.ReviewSelection
Case of
  : (($departement=Null) && ($status=Null))
   return This.query("Date >= :1 AND Date <= :2"; String($year)+"/01/01"; String($year)+"/12/31")

  : (($departement#Null) && ($status=Null))
   return This.query("Employee.ID_Departement = :1 AND Date >= :2 AND Date <= :3"; $departement.ID; String($year)+"/01/01"; String($year)+"/12/31")

  : (($departement=Null) && ($status#Null))
   return This.query("ID_Status = :1 AND Date >= :2 AND Date <= :3"; $status.ID; String($year)+"/01/01"; String($year)+"/12/31")

  : (($departement#Null) && ($status#Null))
   return This.query("Employee.ID_Departement = :1 AND ID_Status = :2 AND Date >= :3 AND Date <= :4"; $departement.ID; $status.ID; String($year)+"/01/01"; String($year)+"/12/31")

Else
  return This.newSelection()
End case


In Qodly Studio wird diese Funktion durch das Ereignis „on data change“ für die Datenquellen Jahr und Status ausgelöst.

Für Jahreseingabe:

Für die Status-Auswahlbox:

Der benutzerdefinierte Filter wird mit der globalen Einschränkung durch on restrict kombiniert, so dass Sie Ihre Ergebnisse unter Berücksichtigung der im Voraus definierten Sicherheitsregeln verfeinern können.

Weiter

Das restrict-Ereignis in 4D erweist sich als leistungsfähiges Werkzeug zur dynamischen Verwaltung des Datenzugriffs. Durch die Nutzung von Benutzerprivilegien und Sitzungsspeicherung gewährleistet es eine granulare Zugriffskontrolle, ohne die Komplexität der Geschäftslogik zu erhöhen. Darüber hinaus bietet die Integration mit ergänzenden Mechanismen wie Promote und das Hinzufügen von benutzerdefinierten Filtern mehr Flexibilität, um spezifische Anforderungen zu erfüllen.

Weitere Informationen zu diesem Thema finden Sie in der offiziellen Dokumentation zu ORDA-Entitäten und im 4D Blog zum Thema Datenfilterung.