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.
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.
- O Explorador de dados também acciona este filtro. Utiliza uma Web Session com o privilégio WebAdmin. Neste exemplo, damos acesso a todos os clientes no Data Explorer devolvendo Null.
- 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:
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.
Descarregue o HDI e descubra mais esta poderosa funcionalidade!