ORDA – Restreindre les données aux critères pertinents

Dans 4D 19 R8, nous avons introduit un système de permission robuste, vous permettant un contrôle granulaire de l’accès des utilisateurs à vos données. Ce système protège vos données en fonction des personnes qui y accèdent et des données auxquelles elles accèdent, garantissant ainsi la sécurité des données en limitant les accès non autorisés.

Mais que se passerait-il si vous vouliez affiner davantage l’accès à la lecture en fonction de critères spécifiques ?

C’est là que 4D 20 R5 intervient. Restreindre les données en lecture en fonction de certains critères.

HDI Restreindre les données

un cas d’utilisation pratique

Grâce au système de permission, vous pouvez donner l’accès en lecture à une classe de données Clients à certains utilisateurs ayant le privilège approprié. C’est très bien, mais si la lecture de la classe de données Clients est autorisée, l’utilisateur peut lire TOUS les clients.

Imaginons, par exemple, une application que les vendeurs utilisent pour conclure des contrats avec leurs clients. Pour protéger la confidentialité, vous pourriez limiter la lecture des clients à ceux gérés par le vendeur authentifié.

Bien sûr, vous pourriez le faire vous-même avec une implémentation personnalisée, mais cela pourrait conduire à un code lourd et difficile à maintenir. Dans votre code, vous devez appliquer votre restriction à chaque endroit où vous lisez des données.

Oubliez cela et écrivez votre critère de restriction une seule fois à un seul endroit, et c’est tout!

Comment mettre en œuvre cette restriction

Comme le titre l’indique, le filtre ne s’applique qu’aux données lues avec ORDA, et les requêtes gérées avec 4D classique ne sont pas prises en compte.

Dans la classe dataclass concernée, vous devez utiliser le mot-clé event pour implémenter une fonction restrict() fonction. Cette fonction doit renvoyer une sélection d’entités de la classe de données concernée.

Dans l’implémentation, vous construisez la sélection d’entités, qui sera appliquée comme un filtre restrictif lorsque vous lirez des données de cette classe de données en utilisant des fonctions telles que query() ou all(). Pour plus de détails, consultez la documentation pour vérifier toutes les autres fonctions concernées par le filtre appliqué.

Voici un exemple d’application utilisée par des vendeurs pour conclure des marchés avec leurs clients. Nous limitons les clients lus à ceux gérés par le vendeur qui utilise l’application.

Cette application est utilisée dans deux contextes :

• en tant que serveur web
• en client-serveur

 

Tout d’abord, voici le modèle de données :

 

Voici la classe de données Clients :

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

L’objet Session est disponible dans un contexte web mais aussi dans un contexte C/S (voir cette nouvelle fonctionnalité)

• Le vendeur s’est authentifié avec un identifiant et un mot de passe. L’identifiant interne du vendeur authentifié est stocké dans la session. Dans la fonction restrict() nous ne renvoyons que les clients gérés par ce vendeur authentifié.

• L’explorateur de données déclenche également ce filtre. Il utilise une session web avec le privilège WebAdmin. Dans cet exemple, nous donnons accès à tous les clients de l’explorateur de données en renvoyant Null.

• Dans d’autres cas, pour des raisons de sécurité, nous renvoyons une sélection d’entités Customers vide pour empêcher la lecture des clients.

 

cet exemple en action

Dans un contexte Web, le vendeur authentifié internalId a été stocké dans la session. Seuls ses clients peuvent être lus lorsqu’une requête /rest/Customers est exécutée sur une page web :

 

Dans un contexte client-serveur, grâce au nouvel objet Session disponible dans C/S, le vendeur authentifié est également stocké dans la session.

Lorsque nous cliquons sur le bouton Get all customers, la fonction Customers.all() est appelée et le même filtre est appliqué.

 

Téléchargez l’HDI et découvrez cette puissante fonctionnalité !