ORDA – Restringir los datos a los criterios pertinentes

Traducido automáticamente de Deepl

En 4D 19 R8, hemos introducido un robusto sistema de permisos, que le garantiza un control granular sobre el acceso de los usuarios a sus datos. Este sistema protege sus datos en función de quién accede a ellos y a qué datos se accede, garantizando la seguridad de los datos al restringir el acceso no autorizado.

Pero, ¿y si quisiera refinar aún más el acceso de lectura en función de criterios específicos?

Ahí es donde interviene 4D 20 R5. Restringir los datos de lectura según algunos criterios.

HDI Restringir datos

un caso práctico

Gracias al sistema de permisos, puede dar acceso de lectura a una clase de datos de Clientes a algunos usuarios que tengan el privilegio apropiado. Eso está muy bien, pero si se concede la lectura de la clase de datos Clientes, el usuario puede leer TODOS los clientes.

Por ejemplo, imagine una aplicación que los vendedores utilizan para hacer tratos con sus clientes. Para proteger la confidencialidad, podría restringir la lectura de clientes a aquellos gestionados por el vendedor autenticado.

Por supuesto, usted podría hacer esto por su cuenta con una implementación personalizada, pero podría dar lugar a un código engorroso y difícil de mantener. En su código, debe aplicar su restricción en cada lugar donde lea datos.

Olvídalo y escribe tus criterios de restricción una vez en un único lugar, ¡y ya está!

Cómo aplicar esta restricción

Como revela el título, el filtro sólo se aplica a los datos leídos con ORDA, y las consultas manejadas con 4D clásico no se tienen en cuenta.

En la clase dataclass en cuestión, debe utilizar la palabra clave event para implementar una función restrict() función. Esta función debe devolver una selección de entidades de la clase de datos en cuestión.

En la implementación, se construye la selección de entidades, que se aplicará como un filtro de restricción cuando se lean datos de esta clase de datos utilizando algunas funciones como query() o all(). Para más detalles, echa un vistazo a la documentación para comprobar todas las demás funciones afectadas por el filtro aplicado.

A continuación se muestra un ejemplo de una aplicación utilizada por los vendedores para hacer tratos con sus clientes. Restringimos los clientes leídos a los gestionados por el vendedor que utiliza la aplicación.

Esta aplicación se utiliza en dos contextos

  • como servidor web
  • en cliente-servidor

En primer lugar, aquí está el modelo de datos:

Aquí está la clase de datos Clientes:


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

El objeto Session está disponible en un contexto web pero también en un contexto C/S (ver esta novedad)

  • El vendedor se autentica con un identificador y una contraseña. El identificador interno del vendedor autentificado se almacena en la Sesión. En la función restrict() sólo se devuelven los clientes gestionados por este vendedor autentificado.
  • En otros casos, por razones de seguridad, devolvemos una selección de entidad Customers vacía para evitar la lectura de clientes.

este ejemplo en acción

En un contexto web, el vendedor autenticado internalId ha sido almacenado en la Sesión. Sólo sus clientes pueden ser leídos cuando se ejecuta una petición /rest/Clientes en una página web:

blank

En un contexto cliente-servidor, gracias al nuevo objeto Session disponible en C/S, el vendedor autentificado también se almacena en la sesión.

Cuando hacemos clic en el botón Obtener todos los clientes, se llama a la función Customers.all() , y se aplica el mismo filtro.

blank

Descargue el IDH y siga descubriendo esta potente función.

Avatar
• Propietario de producto - Marie-Sophie Landrieu-Yvert ingresó al equipo de 4D Product como Propietario de producto en 2017. Como tal, está a cargo de escribir las historias de los usuarios y luego traducirlas en especificaciones funcionales. Su papel es también asegurarse de que la implementación de la funcionalidad entregada cumpla con las necesidades del cliente. Marie-Sophie se graduó en la Escuela de Ingeniería de ESIGELEC y comenzó su carrera como ingeniera en IBM en 1995. Participó en varios proyectos (de mantenimiento y creación) y trabajó como desarrolladora de Cobol. Luego trabajó como diseñadora de UML y desarrolladora de Java. Sus principales funciones fueron analizar y redactar requisitos funcionales, coordinar los equipos de negocio y de desarrollo.