ORDA – Restringir dados a critérios relevantes

Tradução automática de Deepl

Em 4D 19 R8, introduzimos um sistema de permissão robusto, concedendo-lhe um controlo granular sobre o acesso dos utilizadores aos seus dados. Este sistema protege seus dados dependendo de quem acessa e quais dados são acessados, assegurando segurança de dados ao restringir acesso não autorizado.

Mas e se quisesse refinar ainda mais o acesso de leitura baseado em critérios específicos?

É aí que 4D 20 R5 entra em cena. Restringindo dados de leitura de acordo com alguns critérios.

HDI Restringir Dados

um caso prático de uso

Graças ao sistema de permissão, pode dar acesso de leitura a uma classe de dados de Clientes a alguns utilizadores com o privilégio apropriado. Isso é muito bom, mas se a leitura da classe de dados Clientes for concedida, o utilizador pode ler TODOS os clientes.

Por exemplo, imagine uma aplicação que os vendedores utilizam para fazer negócios com os seus clientes. Para proteger a confidencialidade, pode restringir a leitura de clientes aos que são geridos pelo vendedor autenticado.

É claro que poderia fazer isto por si próprio com uma implementação personalizada, mas isso poderia levar a um código pesado e difícil de manter. No seu código, tem de aplicar a sua restrição em cada local de leitura de dados.

Esqueça isso e escreva os seus critérios de restrição uma vez num único local, e já está!

Como implementar esta restrição

Como o título revela, o filtro aplica-se apenas aos dados lidos com ORDA, e as consultas tratadas com 4D clássico não são consideradas.

Na classe de classe de dados em questão, deve usar a palavra-chave event para implementar uma função restrict() função. Esta função deve devolver uma seleção de entidade da classe de dados em causa.

Na implementação, constrói-se a seleção de entidades, que será aplicada como um filtro restritivo quando se lêem dados desta classe de dados utilizando algumas funções como query() ou all(). Para mais pormenores, consulte a documentação para verificar todas as outras funções relacionadas com o filtro aplicado.

Segue-se um exemplo de uma aplicação utilizada por vendedores para efetuar negócios com os seus clientes. Restringimos os clientes lidos aos que são geridos pelo vendedor que utiliza a aplicação.

Esta aplicação é utilizada em dois contextos:

  • como servidor Web
  • em cliente-servidor

Em primeiro lugar, eis o modelo de dados:

Aqui está a classe de classe de dados Customers:


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

O objeto Session está disponível num contexto Web, mas também num contexto C/S (ver esta nova funcionalidade)

  • O vendedor autenticou-se com um identificador e uma palavra-passe. O ID interno do vendedor autenticado é armazenado na Session. Na função restrict() só devolvemos os clientes geridos por este vendedor autenticado.
  • Noutros casos, por razões de segurança, devolvemos uma seleção de entidade Customers vazia para impedir a leitura de clientes.

este exemplo em ação

Num contexto Web, o vendedor autenticado internalId foi armazenado na sessão. Apenas os seus clientes podem ser lidos quando um pedido /rest/Customers é executado numa página Web:

blank

Num contextocliente-servidor, graças ao novo objeto Session disponível no C/S, o vendedor autenticado também é armazenado na sessão.

Quando clicamos no botão Obter todos os clientes, a função Customers.all() é chamada e o mesmo filtro é aplicado.

blank

Descarregue o HDI e descubra mais esta poderosa funcionalidade!

Avatar
• Proprietário do produto - Marie-Sophie Landrieu -Yvert entrou ao time 4D Product como Proprietária do Produto em 2017. Como tal, está a cargo de escrever as histórias dos usuários e depois traduzi-las em especificações funcionais. Seu papel também é garantir que a implementação da funcionalidade entregue cumpra com as necessidades do cliente. Marie-sophie se formou na Escola de Engenharia de ESIGELEC e começou sua carreira como engenheira da IBM em 1995. Participou em vários projetos (de manutenção e criação) e trabalhou como desenvolvedora de Cobol. Depois trabalhou como designer de UML e desenvolvedora de Java. Suas principais funções foram analisar e redigir requisitos funcionais, coordenar os times de negócio e de desenvolvimento.