ORDA – Einschränkung der Daten auf relevante Kriterien

In 4D 19 R8 haben wir ein robustes Berechtigungssystem eingeführt, das Ihnen eine detaillierte Kontrolle über den Benutzerzugriff auf Ihre Daten ermöglicht. Dieses System schützt Ihre Daten in Abhängigkeit davon, wer auf sie zugreift und auf welche Daten zugegriffen wird, und gewährleistet so die Datensicherheit, indem es den unbefugten Zugriff einschränkt.

Was aber, wenn Sie den Lesezugriff anhand bestimmter Kriterien weiter einschränken möchten?

Hier kommt 4D 20 R5 ins Spiel. Einschränkung von gelesenen Daten nach bestimmten Kriterien.

HDI Daten einschränken

ein praktischer Anwendungsfall

Dank des Berechtigungssystems können Sie einigen Benutzern, die über die entsprechenden Berechtigungen verfügen, Lesezugriff auf eine Kundendatenklasse gewähren. Das ist sehr gut, aber wenn der Lesezugriff auf die Datenklasse „Kunden“ gewährt wird, kann der Benutzer ALLE Kunden lesen.

Stellen Sie sich zum Beispiel eine Anwendung vor, mit der Verkäufer Geschäfte mit ihren Kunden abschließen. Um die Vertraulichkeit zu schützen, könnten Sie die gelesenen Kunden auf die beschränken, die von dem authentifizierten Verkäufer verwaltet werden.

Natürlich könnten Sie dies mit einer benutzerdefinierten Implementierung selbst tun, aber das könnte zu schwerfälligem und schwer zu pflegendem Code führen. In Ihrem Code müssen Sie Ihre Einschränkung an jeder Stelle anwenden, an der Sie Daten lesen.

Vergessen Sie es und schreiben Sie Ihre Einschränkungskriterien nur einmal an einer einzigen Stelle, und das war’s!

Wie man diese Einschränkung implementiert

Wie der Titel verrät, gilt der Filter nur für Daten, die mit ORDA gelesen werden, und Abfragen, die mit Classic 4D bearbeitet werden, werden nicht berücksichtigt.

In der betreffenden Datenklassenklasse müssen Sie das Schlüsselwort event verwenden, um eine restrict() Funktion implementieren. Diese Funktion muss eine Entity-Auswahl der betreffenden Datenklasse zurückgeben.

In der Implementierung erstellen Sie die Entity-Auswahl, die als einschränkender Filter angewendet wird, wenn Sie Daten aus dieser Datenklasse mit Hilfe einiger Funktionen wie query() oder all(). Weitere Einzelheiten finden Sie in der Dokumentation, in der Sie alle anderen Funktionen finden, die von dem angewandten Filter betroffen sind.

Im Folgenden finden Sie ein Beispiel für eine Anwendung, die von Verkäufern verwendet wird, um Geschäfte mit ihren Kunden zu tätigen. Wir beschränken die gelesenen Kunden auf diejenigen, die von dem Verkäufer, der die Anwendung verwendet, verwaltet werden.

Diese Anwendung wird in zwei Kontexten verwendet:

  • als Webserver
  • im Client-Server-Betrieb

 

Zunächst ist hier das Datenmodell zu sehen:

 

Hier ist die Kunden-Datenklasse:


Class extends DataClass

Function event restrict() : cs.CustomersSelection
	
// There is a session
If (Session#Null)
		
	Case of 
		: (Session.storage.salesInfo#Null)
		// Only the customers handled by the authenticated salesperson are returned
		return This.query("sales.internalId = :1"; Session.storage.salesInfo.internalId)
				
		// Data explorer 
		: (Session.hasPrivilege("WebAdmin"))
		//No filter is applied
		return Null
				
		Else 
		//No customers can be read
		return This.newSelection()
	End case 
		
Else 
	//No customers can be read
	return This.newSelection()
End if

Das Session-Objekt ist in einem Web-Kontext verfügbar, aber auch in einem C/S-Kontext (siehe diese neue Funktion)

  • Der Verkäufer hat sich mit einer Kennung und einem Kennwort authentifiziert. Die interne ID des authentifizierten Verkäufers wird in der Session gespeichert. In der restrict() Funktion geben wir nur die Kunden zurück, die von diesem authentifizierten Verkäufer verwaltet werden.
  • In anderen Fällen geben wir aus Sicherheitsgründen eine leere Entitätsauswahl Customers zurück, um das Lesen von Kunden zu verhindern.

 

Dieses Beispiel in Aktion

In einem Web-Kontext wurde der authentifizierte Verkäufer internalId in der Session gespeichert. Nur seine Kunden können gelesen werden, wenn eine Anfrage /rest/Customers auf einer Webseite ausgeführt wird:

blank

 

In einem Client-Server-Kontext wird dank des neuen Session-Objekts, das in C/S verfügbar ist, der authentifizierte Verkäufer ebenfalls in der Session gespeichert.

Wenn wir auf die Schaltfläche Get all customers klicken, wird die Funktion Customers.all() aufgerufen und derselbe Filter angewendet.

blank

 

Laden Sie den HDI herunter und entdecken Sie diese leistungsstarke Funktion!

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert ist seit 2017 als Product Owner im 4D Produktteam tätig. Als Product Owner ist sie für das Schreiben der User Stories und deren Umsetzung in funktionale Spezifikationen zuständig. Ihre Aufgabe ist es auch, sicherzustellen, dass die Implementierung der Funktionen den Anforderungen des Kunden entspricht. Marie-Sophie ist Absolventin der ESIGELEC Ingenieurschule und begann ihre Karriere als Ingenieurin bei IBM im Jahr 1995. Sie nahm an verschiedenen Projekten teil (Wartungs- oder Build-Projekte) und arbeitete als Cobol-Entwicklerin. Dann arbeitete sie als UML-Designerin und Java-Entwicklerin. In letzter Zeit bestand ihre Hauptaufgabe darin, funktionale Anforderungen zu analysieren und zu schreiben sowie Geschäfts- und Entwicklungsteams zu koordinieren.