Una migliore comprensione delle sessioni REST 4D

In un precedente post del blog, vi abbiamo mostrato come iniziare a utilizzare il server REST 4D. Vi abbiamo illustrato diverse operazioni CRUD utilizzando Postman e vi abbiamo indicato la documentazione REST completa. In questo post spiegheremo come funzionano le sessioni in 4D. Questa comprensione vi permetterà di costruire un sistema di autenticazione basato sulle sessioni utilizzando il server REST 4D.

Sessioni di riposo in 4D

Se siete interessati a costruire un sistema di autenticazione, un sistema basato sulle sessioni è quello che state cercando!

Le connessioni al server 4D REST sono basate sulle sessioni. Ciò significa che il server 4D crea una sessione alla prima richiesta del client e gli invia un cookie di sessione (WASID4D). Per tutte le richieste successive, il client deve restituire questo cookie di sessione nell’intestazione della richiesta. Ciò è contrario all’autenticazione basata su token, in cui la sessione non viene conservata sul lato server, ma viene memorizzata sul client.

Configurare il server REST

Ora che abbiamo capito bene come vengono gestite le sessioni, andiamo avanti. Prima di iniziare, è necessario avviare e configurare il server REST 4D. Prima di proseguire, consultare questo post del blog o il centro di documentazione.

Metodo di autenticazione REST

The On REST Authentication Il metodo del database offre un modo personalizzato per controllare il modo in cui le sessioni REST vengono aperte su 4D. Quando si riceve una richiesta di apertura di una sessione REST, gli identificatori di connessione(ad esempio, nome utente e password) vengono forniti nell’intestazione della richiesta. Il metodo del database On REST Authentication viene chiamato in modo da poter valutare questi identificatori e restituire True (apertura della sessione accettata) o False (apertura della sessione rifiutata).

Nota: questo metodo è utilizzato per codificare il proprio controllo di accesso al database, ma l’accesso può essere limitato anche utilizzando un gruppo di utenti 4D. Quando si espone il database, selezionare il gruppo a cui è consentito l’accesso nella scheda Impostazioni database > Web > Risorse REST. Consultate questo post del blog per rinfrescarvi la memoria.

Aprire una sessione

Per illustrare l’apertura di una sessione, immaginiamo un modulo di invio con login e password. Utilizzeremo Postman per inviare le credenziali nelle intestazioni della richiesta POST. Per aprire una sessione nell’applicazione 4D tramite REST, utilizzare $directory/login:

Torniamo a 4D e vediamo cosa sta succedendo.

Come si può vedere, il metodo database riceve quattro parametri:

• $1 per il nome dell’utente,
• $2 per la password,
• $3 restituisce True se la password è stata sottoposta a hash e False se non lo è,
• $4 contiene l’indirizzo IP del chiamante.

Nota: nel mondo reale, le password dovrebbero essere sottoposte a hash e non inviate in chiaro. Per inviare una password con hash, si può usare il parametro hashed-password-4D invece di password-4D. Si veda questo esempio di codice che mostra come procedere.

Una volta ricevuta la richiesta, il server apre una sessione e invia al client un cookie di sessione (WASID4D):

Ora che la sessione è stata creata, come possiamo trasmettere il suo ID nelle richieste HTTP successive?

Aspettate… perché dobbiamo fare questo in primo luogo?

Gestione della sessione

L’HTTP è un protocollo “stateless”… ogni volta che un client si connette a una pagina web, apre una connessione separata al server web. Il server non tiene traccia delle richieste precedenti del cliente. Immaginando che migliaia di client si connettano al server, come può sapere quale sessione è la vostra? È qui che entra in gioco l’ID di sessione. Attraverso questo scambio di ID di sessione, lo stato viene mantenuto. Che cosa significa esattamente? Significa che per riutilizzare la stessa sessione, è necessario assicurarsi che tutte le richieste REST successive includano l’ID di sessione nell’intestazione“Cookie” della richiesta. Altrimenti, verrà aperta una nuova sessione (e una nuova sessione significa una nuova licenza).

Esempio

Il modo in cui gestire le sessioni dipende dal client HTTP in uso. Supponiamo di trovarci in un contesto in cui le richieste sono gestite tramite il comando HTTP Request.

Per includere l’ID di sessione nell’intestazione, dobbiamo prima trovarlo. Facile! Sappiamo che la sessione ha una chiave WASID4D, quindi basta cercare questa chiave nei valori delle intestazioni con il comando Find in array:

Find in array($headerValues; "WASID4D@")

Una volta trovata, estraiamola:

$start:=Position("WASID4D";$cookie)
$end :=Position(";";$cookie)
$uuid := Substring($cookie;$start;$end-$start)Il $uuid ospiterà l’ID di sessione che verrà inviato in tutte le richieste successive. Trovate l’esempio completo qui.

Controllare il timeout della sessione

Per impostazione predefinita, il timeout di inattività della sessione è di 60 minuti e non può essere inferiore. Tuttavia, è possibile aumentare la durata del timeout con il valore del parametro“session-4D-length“, che può essere passato nelle intestazioni POST con il metodo $directory/login.

Un’altra cosa

Il server 4D dispone di una sessione che memorizza le selezioni di entità basate su query o comandi d’ordine precedenti. Per questo motivo, quando è necessario il prossimo “intervallo” (o pezzo) di dati, non è necessario eseguire nuovamente la query o l’ordine, ma è sufficiente inviare la serie di dati successiva. Questo meccanismo consente l’uso di transazioni, locking pessimistico e altro ancora.

Cosa c’è di nuovo?

Il server REST è stato notevolmente migliorato con 4D v18 e altre funzionalità sono in arrivo in futuro. Nel frattempo, continueremo a fornirvi esempi e casi d’uso pratici. Sentitevi liberi di partecipare alla discussione sul forum 4D.