Forçar login se torna padrão para todas as autenticações REST

Recentemente, disponibilizámos uma nova forma de controlar o acesso à API REST através dos privilégios e da função ds.authentify: Forçar login. Essa função oferece muito mais do que os mecanismos de autenticação disponíveis anteriormente, e foi claramente explicada nesse post do blog.

Com 4D 20 R6, Force Login é agora o modo padrão para autenticações REST. Quer saber por que e como lidar com essa transição? Continue lendo esse post.

Padrão em novos projetos

Quando cria um projeto no 4D 20 R6, um arquivo roles.json é automaticamente criado na pasta Sources. Esse arquivo inclui o atributo forceLogin definido como“True” e um privilégio“none, que nega acesso a toda a API REST por padrão.

Essa abordagem garante um alto nível de segurança por design.

É possível personalizar as permissões editando o arquivo roles.json fornecido ou usando o editor de funções e privilégios do Qodly Studio para uma experiência mais amigável.

Agora é possível controlar com precisão o acesso REST aos seus dados e funções!

E quanto aos projetos existentes?

Para projetos existentes, um novo botão na aba Web/Web Features do diálogo Structure Settings permite converter seu projeto para Force Login.

Ao clicar nesse botão, 4D vai

  • Removerá o grupo de usuários com acesso de leitura/escrita à API REST das configurações.
  • Mover o método de banco de dados “On REST Authentication” para a lixeira do sistema.
  • Criar um arquivo “roles.json” na pasta Sources se ele ainda não existir, configurando seu atributo forceLogin para True.

 

Lembre-se de reiniciar o projeto após realizar essa conversão. Se o botão não for exibido, seu projeto já é compatível com o Force Login.

Mudando de configurações legadas

Até a introdução do Force Login, você tinha três opções para o controle de acesso REST. Explicamos a seguir como imitar todas elas quando o Force Login estiver ativado.

Nestes exemplos, usaremos um privilégio de “Administrador” criado no editor de Funções e Privilégios do Qodly Studio: blank

1: Servidor exposto como Rest sem grupo de acesso

A primeira opção consistia em expor o servidor REST sem definir um grupo de acesso ou filtrar os pedidos no método de base de dados “On REST Authentication”.
Para reproduzir este comportamento com o Force Login, basta dar acesso total a toda a API REST:

Class extends DataStoreImplementation
exposed Function authentify() : Boolean
return Session .setPrivileges("Administrator")

Note-se que esta implementação não é recomendada porque carece de segurança. Todos os dados e funções estão acessíveis a toda a gente.

2: Servidor exposto como Rest com grupo de acesso definido

A segunda opção foi definir um grupo de usuários 4D com acesso de leitura/escrita à API REST.
Para reproduzir esse comportamento, simplesmente verifique as credenciais e dê acesso total aos membros do grupo de Leitura/Escrita que foi definido no diálogo Structure Settings (o grupo “RestAccess” nesse exemplo):

Class extends DataStoreImplementation
exposed Function authentify($identifier: Text; $pwd: Text) : Boolean
If ($identifier#"")
If (Validate password($identifier; $pwd)
If (User in group($identifier; "RestAccess"))
return Session .setPrivileges("Administrador")
End if
End if
End if

Esta restrição protege o acesso aos dados e as funções contra ligações maliciosas. Cada ligação autorizada tem os mesmos direitos.

3: método de autenticação em repouso

A terceira opção consistia em verificar as credenciais do utilizador utilizando o método de base de dados “On REST Authentication”. Este método era frequentemente utilizado para verificar os acessos a partir de um sistema de gestão de utilizadores personalizado. Para reproduzir esse comportamento, você pode praticamente copiar o código do método “On REST Authentication” na função ds.authentify(), como neste exemplo.

O método original “On REST Authentication”:

#DECLARE($identifier: Text; $pwd: Text) : Boolean
If ($identifier#"")
var $user : cs.UserEntity:=ds.User.query("identifier = :1"; $identifier).first()
If ($user#Null)
If (Verify password hash($pwd; $user.pwd))
return True
End if
End if
End if

A função de substituição “ds.authentify()”:

Class extends DataStoreImplementation
exposed Function authentify($identifier: Text; $pwd: Text) : Boolean
If ($identifier#"")
var $user : cs.UserEntity:=ds.User.query("identifier = :1"; $identifier).first()
If ($user#Null)
If (Verify password hash($pwd; $user.pwd))
return Session.setPrivileges("Administrador")
End if
End if
End if

Tal como na opção anterior, cada ligação autorizada tem os mesmos direitos; o acesso aos dados e às funções tem de ser codificado pelo utilizador.

Próximo nível

O poder do Force Login é que você pode aplicar a mesma lógica comercial e as restrições que deseja às conexões REST. Isso é particularmente verdadeiro para solicitações de páginas Qodly, conexões de datastore remoto ou solicitações REST externas.
No exemplo seguinte, em vez de definir o privilégio “Administrador” quando o utilizador é autenticado, definimos simplesmente os privilégios armazenados na entidade do utilizador. Isso permite dar acesso refinado ao repositório de dados, às classes de dados, aos atributos de classe de dados e às funções desejadas e restringir todo o resto!

Class extends DataStoreImplementation
exposed Function authentify($credentials: Object) : Boolean
If ($credentials#Null)
var $user : cs.UserEntity:=ds.User.query("identifier = :1"; $credentials.identifier).first()
If ($user#Null)
If (Verify password hash($credentials.pwd; $user.pwd))
return Session.setPrivileges($user.privileges)
End if
End if
End if

 

Para concluir

O Force Login proporciona um controlo preciso do acesso aos seus dados e funções a partir da API REST. Permite-lhe usar a lógica de acesso do código para as permissões definidas, evitando assim erros de código no acesso e oferecendo um nível de segurança mais fiável. Esta camada de segurança integrada é muito mais precisa, uma vez que é possível definir as permissões para cada elemento do datastore (o próprio datastore, as classes de dados, os atributos das classes de dados, as funções) e atribuir direitos a cada um deles (Criar, Ler, Atualizar, Eliminar, etc.).
Defina os seus privilégios e utilize o editor de funções e privilégios do Qodly Studio para uma experiência melhorada.
Compartilhe seu feedback sobre essa caraterística nos Fóruns 4D!

Avatar
• Proprietário do produto - Damien Fuzeau entrou ao time 4D Product em fevereiro de 2019. Como Proprietário do Produto, 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. Damien é formado em engenharia de software pela Universidade de Nantes. Trabalhou mais de 23 anos em sua empresa anterior, primeiro como desenvolvedor (descobrindo 4D em 1997), e mais tarde como gerente de engenharia e arquiteto de software. Essa empresa é um Partner OEM de 4D e lançou softwares empresariais baseados em 4D para milhares de usuários em centenas de servidores. Portanto Damien está acostumado ao desenvolvimento e lançamento de 4D em contextos multilinguais.