Gestion des sessions Web

4D v19.8

Note de compatibilité

Cette page décrit les anciennes sessions Web disponibles dans les bases de données 4D converties (voir Anciennes sessions (sessions process uniques)).

A partir de 4D v18 R6, il est recommandé d'utiliser l'implémentation des sessions Web extensibles. Vous pouvez activer des sessions extensibles dans vos applications converties en sélectionnant l'option appropriée dans les paramètres de l'application, la fonction webServer.start( ) ou via la commande WEB SET OPTION.

Une documentation complète des sessions Web extensibles est disponible dans la page Sessions utilisateur sur developer.4d.com.

Overview

Le serveur Web de 4D propose un mécanisme simple et complet de gestion des sessions utilisateur. Ce mécanisme automatique permet à des clients Web de réutiliser le même contexte (sélections et instances de variables) lors de requêtes successives.

Ce principe est basé sur l’utilisation d’un cookie privé posé par 4D lui-même : "4DSID". À chaque requête d’un client Web, 4D contrôle la présence et la valeur du cookie 4DSID :

si le cookie a une valeur, 4D tente de retrouver le contexte d’origine du cookie parmi les contextes existants,
- si le contexte est trouvé, il est réutilisé pour la requête, la méthode Compiler_Web n’est pas exécutée,
- si aucun contexte n’est trouvé, 4D en crée un nouveau,
si le cookie n’a pas de valeur ou s'il n'est pas présent (pour cause d'expiration par exemple), 4D crée un nouveau contexte.

Activation et inactivation du mécanisme

Le mécanisme de gestion des sessions doit être activé sur votre serveur Web 4D pour que vous puissiez en bénéficier dans votre application.

Par défaut, ce mécanisme est activé dans les bases de données créées avec 4D v13 et suivantes. En revanche, pour des raisons de compatibilité, il est inactivé dans les bases de données converties depuis une version précédente de 4D. Vous devez l’activer explicitement pour pouvoir bénéficier de cette nouvelle fonctionnalité.

Vous pouvez gérer l’activation de la gestion automatique des sessions de deux manières :

via l'option Gestion automatique des sessions dans la page "Options (I)" des Propriétés de la base :

Dans ce cas, le paramétrage est permanent, il est stocké sur disque.
via l’option Web Keep session de la commande WEB SET OPTION. Dans ce cas, le paramétrage est défini pour la session uniquement et "surcharge" celui défini dans les propriétés de la base.

Dans les deux cas, le paramétrage est local au poste ; il peut donc différer entre le serveur Web de 4D Server et des serveurs Web 4D distants.

Expiration des cookies et conservation des contextes

La durée de vie du cookie en cas d’inactivité est de 8 heures par défaut (480 minutes) et est modifiable l’aide de la commande WEB SET OPTION. Il est possible de définir une durée de vie différente pour les cookies (option Web inactive session timeout) et pour les process associés aux sessions sur le serveur (option Web inactive process timeout) : vous pouvez souhaiter par exemple qu’un "panier" reste valide pendant 24 heures mais, pour des raisons d’optimisation, vous ne voulez pas maintenir de process aussi longtemps. Dans ce cas, vous pouvez fixer une durée de vie du process de 4 heures par exemple. A l’issue de ce délai, la Méthode base Sur fermeture session Web ancienne est appelée, vous permettant de stocker les variables et les sélections liées à la session, puis le process est tué. A la prochaine connexion du client Web (jusqu’à 24 heures plus tard), le cookie est renvoyé au serveur et vous pourrez recharger les informations de la session dans la QR SET DESTINATION (cf. exemple ci-dessous).

Si nécessaire, vous pouvez forcer à tout moment l'expiration du cookie et donc clore la session à l'aide de la commande WEB LEGACY CLOSE SESSION.

Destruction des contextes inactifs

4D détruit automatiquement les plus anciens contextes inactifs lorsque le nombre maximum de contextes conservés est atteint (ce nombre de 100 par défaut peut être modifié à l’aide de la commande WEB SET OPTION).
Lorsqu’un contexte est sur le point d’être détruit (fermeture du process Web associé), la Méthode base Sur fermeture session Web ancienne est appelée, vous permettant de stocker les variables et les sélections du contexte, en prévision de réutilisations futures.

Exemple

Cet exemple illustre la simplicité de mise en oeuvre des sessions via les méthodes base Sur connexion Web et Sur fermeture session Web.

Voici le code de la QR SET DESTINATION :

  // Sur connexion Web (ou Sur authentification Web)

 C_TEXT(www_SessionID)

 If(www_SessionID=WEB Get Current Session ID)

  // Compiler_Web n’a pas été appelé

  // Toutes les variables et les sélections existent

    ...

 Else

  // Compiler_Web vient d’être exécuté

  // On est dans une nouvelle session, aucune variable ou sélection n’est définie.

  // On stocke l’id de la nouvelle session

    www_SessionID:=WEB Get Current Session ID

 

  // Initialisation de la session

  // Définition des sélections

  // Récupération de l’utilisateur sélectionné

    QUERY([User];[User]Login=www_Login)

    QUERY([prefs];[prefs]Login=www_Login)

  // Coordonnées de l’employé

    QUERY([emps];[emps]Name=[user]name)

    QUERY([company];[company]Name=[user]company)

 

  // Définition des variables

  // Lecture des préférences de cet utilisateur

    SELECTION TO ARRAY([prefs]name;prefNames;[prefs]values;prefValues)

    www_UserName:=[User]Name

    www_UserMail:=[User]mail

 

  // Fin d’initialisation de la session

 End if

Voici le code de la Méthode base Sur fermeture session Web ancienne :

  // Sur fermeture session Web

  // Après une période d’inactivité ou en cas de besoin, 4D ferme la session

 C_TEXT(www_SessionID)

 www_SessionID:=""

  // On stocke des informations de la session

  // On enregistre les préférences de l’utilisateur précédemment connecté

 QUERY([prefs];[prefs]Login=www_Login) // conservé dans la session

 ARRAY TO SELECTION(prefNames;[prefs]name;prefValues;[prefs]values)

 

  // Important : le process est ensuite détruit

  // 4D efface les variables, les sélections, etc.

Cas du rejet des cookies

Le mécanisme de gestion des sessions étant basé sur l’utilisation de cookies, il ne sera pas possible au serveur HTTP de 4D de maintenir une session si le client Web rejette les cookies. Dans ce cas, chaque requête sera traitée comme une nouvelle connexion et provoquera l’exécution de la méthode Compiler_Web.

Il est possible de vérifier que le client Web prend en charge les cookies à l’aide de la commande WEB GET HTTP HEADER.

Sessions et gestion des adresses IP

Le serveur HTTP de 4D enregistre l’IP qui a débuté une session. Si un client Web situé à une adresse IP différente tente d’accéder à une session existante, l’erreur HTTP 400 est retournée au client.

Voir aussi

_O_WEB Get session process count
Méthode base Sur fermeture session Web ancienne
On Web Legacy Close Session database method
WEB Get Current Session ID
WEB LEGACY CLOSE SESSION
WEB LEGACY GET SESSION EXPIRATION