Dans un précédent article de blog, nous vous avons montré comment démarrer avec le serveur REST de 4D. Nous vous avons guidé à travers différentes opérations CRUD en utilisant Postman et nous vous avons indiqué la documentation REST complète. Dans ce billet de blog, nous allons expliquer comment les sessions fonctionnent dans 4D. Cette compréhension vous permettra de construire un système d’authentification basé sur les sessions à l’aide du serveur 4D REST.
Sessions 4D rest
Si vous souhaitez construire un système d’authentification, un système basé sur les sessions est ce que vous recherchez !
Les connexions au serveur 4D REST sont basées sur des sessions. Cela signifie que le serveur 4D crée une session lorsque la première demande est envoyée par le client et lui renvoie un cookie de session (WASID4D). Pour toutes les demandes suivantes, le client doit renvoyer ce cookie de session dans l’en-tête de la demande. Ceci est contraire à l’authentification basée sur les jetons où aucune session n’est persistée du côté du serveur, mais est stockée sur le client.
Configurer le serveur REST
Maintenant que nous avons une bonne compréhension de la façon dont les sessions sont gérées, allons de l’avant. Avant de commencer, vous devez démarrer et configurer le serveur REST de 4D. Veuillez vous référer à cet article de blog ou au centre de documentation avant d’aller plus loin.
Méthode d’authentification REST
The On REST Authentication La méthode de la base de données REST vous offre un moyen personnalisé de contrôler la façon dont les sessions REST sont ouvertes sur 4D. Lorsqu’une demande d’ouverture d’une session REST est reçue, les identifiants de connexion(par exemple, le nom d’utilisateur et le mot de passe) sont fournis dans l’en-tête de la demande. La méthode de la base de données On REST Authentication est appelée pour pouvoir évaluer ces identifiants et renvoyer True (ouverture de session acceptée) ou False (ouverture de session refusée).
Remarque: Bien que cette méthode soit utilisée pour coder votre propre contrôle d’accès à la base de données, l’accès peut également être restreint en utilisant un groupe d’utilisateurs 4D. Lorsque vous exposez la base de données, sélectionnez le groupe autorisé à accéder dans l’onglet Paramètres de la base de données > Web > Ressource REST. Consultez cet article de blog pour vous rafraîchir la mémoire.
Ouvrir une session
Pour illustrer l’ouverture d’une session, nous imaginons un formulaire de soumission avec un identifiant et un mot de passe. Nous utiliserons Postman pour envoyer les informations d’identification dans les en-têtes de la requête POST. Afin d’ouvrir une session dans votre application 4D via REST, utilisez $directory/login:
Retournons dans 4D et voyons ce qui se passe.
Comme vous pouvez le voir, la méthode database reçoit quatre paramètres :
- $1 pour le nom d’utilisateur,
- $2 pour le mot de passe,
- $3 renvoie True si le mot de passe est haché et False s’il ne l’est pas,
- $4 contient l’adresse IP de l’appelant.
Note: Dans le monde réel, les mots de passe doivent être hachés et non envoyés en clair. Pour envoyer un mot de passe haché, vous pouvez utiliser le paramètre hashed-password-4D au lieu de password-4D. Consultez cet exemple de code qui montre comment procéder.
Une fois la demande reçue, le serveur ouvre une session et renvoie un cookie de session au client (WASID4D) :
Maintenant que notre session a été créée, comment pouvons-nous renvoyer son ID dans les demandes HTTP suivantes ?
Attendez … pourquoi devons-nous faire cela en premier lieu ?
Gestion des sessions
HTTP est un protocole « sans état »… chaque fois qu’un client se connecte à une page Web, il ouvre une connexion distincte avec le serveur Web. Le serveur ne garde pas trace des demandes précédentes du client. Imaginez que des milliers de clients se connectent au serveur, comment pourrait-il savoir quelle session est la vôtre ? C’est là que l’ID de session entre en jeu. Grâce à cet échange d’ID de session, l’état est maintenu. Qu’est-ce que cela signifie exactement ? Pour réutiliser la même session, vous devez veiller à ce que toutes les demandes REST ultérieures incluent l’ID de session dans l’en-tête« Cookie » de la demande. Sinon, une nouvelle session sera ouverte (et une nouvelle session signifie une nouvelle licence).
Exemple
La façon de gérer les sessions dépend en fait de votre client HTTP. Disons que nous sommes dans un contexte où les demandes sont traitées par la commande HTTP Request.
Pour inclure l’ID de session dans l’en-tête, nous devons d’abord le trouver. C’est facile ! Nous savons que la session possède une clé WASID4D, il nous suffit donc de rechercher cette clé dans les valeurs des en-têtes avec la commande Find in array:
Find in array($headerValues; "WASID4D@")
Une fois trouvée, nous allons l’extraire :
$start:=Position("WASID4D" ;$cookie)
$end :=Position(" ;";$cookie)
$uuid := Substring($cookie;$start;$end-$start)Le $uuid hébergera l’ID de session qui sera envoyé dans toutes les requêtes suivantes. Retrouvez l’exemple complet ici.
Contrôlez le délai d’inactivité de la session
Par défaut, le délai d’ inactivité de la session est de 60 minutes et ne peut être inférieur. Cependant, vous pouvez augmenter la durée du timeout avec la valeur du paramètre« session-4D-length » qui peut être passé dans les headers POST avec la méthode $directory/login.
Une dernière chose
Le serveur 4D possède une session qui stocke les sélections d’entités basées sur les requêtes ou les commandes précédentes. C’est pourquoi, lorsque le prochain « intervalle » (ou morceau) de données est nécessaire, il n’est pas nécessaire d’effectuer une nouvelle requête/commande, il suffit d’envoyer le prochain ensemble de données. Ce mécanisme permet l’utilisation de transactions, de verrouillages pessimistes, et plus encore.
Quelles sont les prochaines étapes ?
Le serveur REST a été grandement amélioré avec 4D v18, et d’autres fonctionnalités sont à venir. En attendant, nous continuerons à vous fournir des exemples et des cas d’utilisation pratiques. N’hésitez pas à participer à la discussion sur le forum 4D.