ORDA – Limitare i dati ai criteri rilevanti

Tradotto automaticamente da Deepl

In 4D 19 R8 abbiamo introdotto un robusto sistema di autorizzazioni che consente un controllo granulare sull’accesso degli utenti ai dati. Questo sistema protegge i vostri dati a seconda di chi vi accede e di quali dati vi accedono, garantendo la sicurezza dei dati attraverso la limitazione degli accessi non autorizzati.

Ma se si volesse affinare ulteriormente l’accesso in lettura in base a criteri specifici?

È qui che interviene il 4D 20 R5. Limitare la lettura dei dati in base ad alcuni criteri.

HDI Limitare i dati

un caso d’uso pratico

Grazie al sistema di permessi, è possibile concedere l’accesso in lettura a una classe di dati dei Clienti ad alcuni utenti che hanno i privilegi appropriati. Questo è ottimo, ma se la lettura della classe di dati Clienti è concessa, l’utente può leggere TUTTI i clienti.

Ad esempio, immaginiamo un’applicazione che i venditori utilizzano per concludere accordi con i clienti. Per proteggere la riservatezza, si potrebbe limitare la lettura dei clienti a quelli gestiti dal venditore autenticato.

Naturalmente, si potrebbe fare da soli con un’implementazione personalizzata, ma ciò potrebbe portare a un codice ingombrante e difficile da mantenere. Nel codice, è necessario applicare la restrizione in ogni punto in cui si leggono i dati.

Dimenticatevi di scrivere i criteri di restrizione una sola volta in un unico punto e il gioco è fatto!

Come implementare questa restrizione

Come si evince dal titolo, il filtro si applica solo ai dati letti con ORDA, mentre le query gestite con il 4D classico non vengono considerate.

Nella classe dataclass interessata, è necessario utilizzare la parola chiave event per implementare una funzione restrict() funzione. Questa funzione deve restituire una selezione di entità della classe di dati interessata.

Nell’implementazione, si costruisce la selezione di entità, che sarà applicata come filtro restrittivo quando si leggono i dati da questa classe di dati usando alcune funzioni come query() o all(). Per maggiori dettagli, consultare la documentazione per verificare tutte le altre funzioni interessate dal filtro applicato.

Di seguito è riportato un esempio di applicazione utilizzata dai venditori per concludere accordi con i clienti. Limitiamo i clienti letti a quelli gestiti dal venditore che utilizza l’applicazione.

Questa applicazione viene utilizzata in due contesti:

  • come server web
  • in client-server

Innanzitutto, ecco il modello dei dati:

Ecco la classe di dati Clienti:


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’oggetto Session è disponibile in un contesto web, ma anche in un contesto C/S (si veda questa nuova funzionalità).

  • Il venditore si è autenticato con un identificativo e una password. L’ID interno del venditore autenticato è memorizzato nella Sessione. Nella restrict() vengono restituiti solo i clienti gestiti da questo venditore autenticato.
  • In altri casi, per motivi di sicurezza, restituiamo una selezione di entità Clienti vuota per impedire la lettura dei clienti.

questo esempio in azione

In un contesto web, il venditore autenticato internalId è stato memorizzato nella sessione. Solo i suoi clienti possono essere letti quando viene eseguita una richiesta /rest/Clienti su una pagina web:

blank

In un contesto client-server, grazie al nuovo oggetto Session disponibile in C/S, anche il venditore autenticato viene memorizzato nella sessione.

Facendo clic sul pulsante Ottieni tutti i clienti, viene richiamata la funzione Customers.all() e viene applicato lo stesso filtro.

blank

Scaricate l’HDI e scoprite questa potente funzione!

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert è entrata a far parte del team 4D Product come Product Owner nel 2017. In qualità di Product Owner, è incaricata di scrivere le storie degli utenti e di tradurle in specifiche funzionali. Il suo ruolo è anche quello di assicurarsi che l'implementazione della funzionalità fornita soddisfi le esigenze del cliente.Marie-Sophie si è laureata presso la scuola di ingegneria ESIGELEC e ha iniziato la sua carriera come ingegnere presso IBM nel 1995. Ha partecipato a vari progetti (di manutenzione o di costruzione) e ha lavorato come sviluppatrice Cobol. In seguito ha lavorato come progettista UML e sviluppatore Java. Ultimamente i suoi ruoli principali erano l'analisi e la scrittura dei requisiti funzionali, il coordinamento dei team di business e di sviluppo.