Aqueles que começaram a usar Qodly Studio for 4D já sabem o quão poderosa é esta nova ferramenta para desenvolver aplicações web de negócios. Se ainda não o fez, encontre aqui mais informações sobre como começar.
As aplicações feitas com Qodly Studio for 4D dependem das APIs REST. 4D 20 R5 é lançado com uma nova e ótima funcionalidade: Modo “Force Login”.
Com o modo Force Login, uma licença de Cliente 4D só é consumida quando os usuários fizerem login com sucesso e começarem a trabalhar com os dados e a lógica de sua aplicação.
Continue lendo para saber mais! E não se esqueça de baixar nosso demo para ver isso em ação!
O que é o Modo Forçar Login?
Os formulários web da Qodly não são HTML. De facto, Qodly Studio for 4D descreve o seu formulário como um arquivo JSON, mais tarde renderizado no navegador web do utilizador final como HTML.
Para que um formulário Qodly seja apresentado no navegador web do utilizador final, é desencadeado um pedido REST a partir do navegador para descarregar o JSON do formulário a partir do servidor.
Outras ações do usuário final no formulário também acionam pedidos REST para lidar com dados e chamar funções das classes do modelo de dados ORDA no servidor.
Antes do 4D 20 R5, como para qualquer outro pedido REST, o servidor cria e mantém uma sessão web para hospedar o armazenamento e privilégios da sessão, e uma licença 4D Client é consumida simultaneamente.
Consequentemente, se implementar um formulário de autenticação simples (entradas de login + senha) com Qodly Studio para 4D, assim que seu usuário final chegar a esse formulário, uma licença 4D Client é consumida antes mesmo do processo de autenticação começar.
A licença de cliente 4D consumida só é liberada quando a sessão web for fechada depois de um tempo de inatividade de pelo menos uma hora (ou uma reinicialização do servidor). Isso pode levar a uma falta de licenças de cliente 4D disponíveis para permitir que os usuários trabalhem com sua aplicação.
Estamos cientes de que esse comportamento pode ser melhorado, por isso:
Com 4D 20 R5, pode usar o novo modo “Force login” enquanto trabalha com as APIs REST.
Esse modo beneficia muito Qodly Studio para aplicações 4D já que melhora esse processo. Ajuda a controlar o consumo de licenças de cliente 4D, e agora pode libertar uma licença de cliente 4D quando o usuário termina de usar a aplicação.
Para resumir
Com o modo Force Login, as licenças são consumidas apenas quando os usuários começam a trabalhar com os dados e lógica que seu servidor REST serve. Isso significa:
- Redução do consumo de licenças: Os formulários de logon não consomem mais licenças.
- Experiência do usuário aprimorada: Os usuários podem tentar fazer logon sem afetar as licenças disponíveis.
- Melhor gerenciamento de recursos: A licença é libertada assim que um utilizador sai da aplicação.
Libere uma licença 4D Client a qualquer momento
A sessão pode ser encerrada simplesmente ativando a ação padrão Logout, e uma licença 4D Client pode ser liberada.
Essa é uma melhoria significativa, então vamos mergulhar em mais detalhes para aprender como pode se beneficiar dessa funcionalidade.
Como ativar o modo Force Login
Ativar o modo Force Login é simples. Basta navegar até a seção Roles and Privileges e ativá-lo.
Isso atualiza o arquivo roles.json do seu projeto de acordo.
{
"permissões": {
"allowed": [
]
},
"privileges": [
],
"roles": [
],
"forceLogin": true
}
Análise detalhada do comportamento
Quando este modo é ativado:
- Solicitações REST descritivas(ou seja, solicitações como rest/$catalog ou rest/$getWebForm para renderizar um formulário da Web) não consomem nenhuma licença.
- Outros pedidos REST(por exemplo, pedidos que tratam dados ou chamam funções de classes do modelo de dados ORDA) são rejeitados até que a autenticação seja concluída com êxito.
- É necessário implementar uma função cujo nome deve ser authentify() na classe do armazenamento de dados. Esta função trata da autenticação. Este é o único pedido REST descritivo aceite sem uma autenticação bem sucedida.
Uma vez que a autenticação é bem sucedida, todos os pedidos REST são aceitos, e uma licença de cliente 4D é consumida.
Uma autenticação bem sucedida significa chamar a função Session.setPrivileges().
Aqui está a linha do tempo disso:
Exemplo: Aplicação de vendedor
Este exemplo apresenta uma aplicação que os vendedores utilizam para trabalhar com os ficheiros dos seus clientes.
O utilizador final processa um formulário Web com um datasource do tipo seleção de entidade (classe de dados Customers) com o valor inicial All.
Este erro é recebido porque ainda não foi efetuada uma autenticação bem sucedida:
No entanto, o utilizador final pode renderizar este formulário web simples que não manipula dados ou chama qualquer função quando carregado. Nenhuma licença 4D Client é consumida neste momento.
Quando o usuário final clica no botão Go, a função authentify() é chamada. Ela foi implementada na classe datastore.
exposed Function authentify($credentials : Object) : Text
var $salesPersons : cs.SalesPersonsSelection
var $sp : cs.SalesPersonsEntity
$salesPersons:=ds.SalesPersons.query("identifier = :1"; $credentials.identifier)
$sp:=$salesPersons.first()
If ($sp#Null)
If (Verify password hash($credentials.password; $sp.password))
Session.clearPrivileges()
Session.setPrivileges("")
return "Authentication successful"
Else
return "Wrong password"
End if
Else
return "Wrong user"
End if Esta chamada é aceita.
Se a autenticação falhar, a função Session.setPrivileges() não é chamada. Assim, nenhuma licença é consumida + nenhum pedido REST descritivo permanece rejeitado.
Se a autenticação for bem sucedida, a função Session.setPrivileges() é chamada. Assim, uma licença de cliente 4D é consumida, e qualquer pedido REST é agora aceite. Pode então começar a trabalhar eficientemente com seus dados.
Nota: Nesse exemplo, uma string vazia é passada para a função Session. Use the setPrivileges() para autenticar como um convidado. Naturalmente, os privilégios correspondentes à autenticação dos utilizadores podem ser definidos.
Além disso, pode oferecer aos seus utilizadores finais uma funcionalidade de desconexão graças à ação padrão de terminar sessão mencionada acima. A sessão será destituída dos seus privilégios e o utilizador final voltará ao “estado não autenticado”: só são aceites pedidos REST descritivos e o utilizador tem de se autenticar novamente para trabalhar com os dados.
Conclusão
Com o modo Force Login em 4D 20 R5, pode otimizar o consumo de licenças de cliente 4D em seu Qodly Studio para aplicações web 4D. Isso melhora a experiência do usuário e a gestão de recursos do servidor. Deixe-nos saber o que pensa sobre essa caraterística nos Fóruns 4D!