Num post de blog anterior, mostrámos-lhe como começar com o servidor 4D REST. Acompanhámo-lo em diferentes operações CRUD utilizando o carteiro e indicámos-lhe a documentação REST completa. Neste post do blog, explicar-lhe-emos como funcionam as sessões em 4D. Este entendimento irá garantir que poderá construir um sistema de autenticação baseado em sessões usando o servidor 4D REST.
Sessões de descanso 4D
Se está interessado em construir um sistema de autenticação, um sistema baseado em sessões é o que procura!
As ligações para o servidor 4D REST são baseadas em sessão. Isto significa que o servidor 4D cria uma sessão quando o primeiro pedido é enviado pelo cliente e devolve-lhe um cookie de sessão (WASID4D). Para todos os pedidos subsequentes, o cliente deve devolver este cookie de sessão no cabeçalho do pedido. Isto é contrário à autenticação baseada em fichas onde nenhuma sessão é persistida no lado do servidor, mas é armazenada no cliente.
Configurar o servidor REST
Agora que temos uma boa compreensão de como as sessões são tratadas, vamos avançar. Antes de podermos começar, é necessário iniciar e configurar o servidor 4D REST. Por favor consulte este post no blog ou o centro de documentação antes de prosseguir.
Sobre o método de autenticação REST
The On REST Authentication O método de base de dados fornece-lhe uma forma personalizada de controlar como as sessões REST são abertas em 4D. Quando é recebido um pedido de abertura de uma sessão REST, os identificadores de ligação(por exemplo, nome de utilizador e palavra-passe) são fornecidos no cabeçalho do pedido. O método da base de dados On REST Authentication é chamado para que se possa avaliar estes identificadores, e retornar Verdadeiro (abertura de sessão aceite) ou Falso (abertura de sessão rejeitada).
Nota: Embora este método de base de dados seja utilizado para codificar o seu próprio controlo de acesso à base de dados, o acesso também pode ser restringido utilizando um grupo de utilizadores 4D. Ao expor a base de dados, seleccione o grupo de acesso permitido no separador Database Settings > Web > REST resource. Consulte este post do blogue para uma actualização da memória.
Abrir uma sessão
Para ilustrar a abertura de uma sessão, estamos a imaginar um formulário de submissão com um login e senha. Vamos utilizar o carteiro para enviar as credenciais nos cabeçalhos do pedido de POST. Para abrir uma sessão no seu pedido 4D através de REST, utilize o directório $/login:
Voltemos ao 4D e vejamos o que se está a passar.
Como pode ver, o método da base de dados recebe quatro parâmetros:
- $1 para o nome do utilizador,
- $2 pela palavra-passe,
- $3 devolve Verdadeiro se a palavra-passe for hashed e Falso se não for,
- $4 detém o endereço IP do autor da chamada.
Nota: No mundo real, as palavras-passe devem ser apresentadas apressadamente e não enviadas de forma clara. Para enviar uma palavra-passe em hash pode utilizar o parâmetro hashed-password-4D em vez de password-4D. Veja este exemplo de código que mostra como proceder.
Uma vez recebido o pedido, o servidor abre uma sessão e envia de volta um cookie de sessão para o cliente (WASID4D):
Agora que a nossa sessão foi criada, como podemos passar o seu ID de volta em pedidos HTTP consequentes?
Espere … porque é que temos de fazer isto em primeiro lugar?
Gestão da sessão
HTTP é um protocolo “stateless” … cada vez que um cliente se liga a uma página web, abre uma ligação separada ao servidor web. O servidor não mantém um registo de quaisquer pedidos anteriores de clientes. Imagine milhares de clientes ligados ao servidor, como saberia qual é a sua sessão? É aí que entra em jogo a identificação da sessão. Através desta troca de IDs de sessão, o estado é mantido. O que é que isso significa exactamente? Bem, significa que para reutilizar a mesma sessão, é necessário assegurar que todos os pedidos REST subsequentes incluam o ID da sessão no cabeçalho“Cookie” do pedido. Caso contrário, será aberta uma nova sessão (e uma nova sessão significa uma nova licença).
Exemplo
A forma de lidar com as sessões depende realmente do seu cliente HTTP. Digamos que nos encontramos num contexto em que os pedidos são tratados através do comando HTTP Request.
Para incluir o ID da sessão no cabeçalho, precisamos primeiro de o encontrar. Fácil! Sabemos que a sessão tem uma chave WASID4D, por isso só precisamos de procurar esta chave nos valores dos cabeçalhos com o comando Find in array:
Find in array($headerValues; "WASID4D@")
Uma vez encontrado, vamos extraí-lo:
$start:=Position("WASID4D";$cookie)
$end :=Position(";";";$cookie)
$uuid := Substring($cookie;$start;$end-$start)O $uuid acolherá o ID da sessão que será enviado em todos os pedidos subsequentes. Encontre aqui o exemplo completo.
Controle o tempo limite da sessão
Por defeito, o tempo limite de inactividade da sessão é de 60 min e não pode ser inferior. Contudo, pode aumentar o tempo limite com o valor do parâmetro“session-4D-length” que pode ser passado nos cabeçalhos POST com o método $directory/login.
Mais uma coisa
4D Server tem uma sessão que armazena selecções de entidades com base em consultas anteriores ou comandos de encomenda. É por isso que quando o próximo “intervalo” (ou pedaço) de dados é necessário, não precisa de consultar/encomendar novamente, precisa simplesmente de enviar o próximo conjunto de dados. Este mecanismo permite a utilização de transacções, bloqueio pessimista, e muito mais.
O que se segue?
O servidor REST foi grandemente melhorado com 4D v18, e mais funcionalidades estão a chegar no futuro. Entretanto, vamos continuar a fornecer-lhe exemplos e casos de utilização prática. Esteja à vontade para se juntar à discussão no fórum 4D.