Exporter (0) Imprimer
Développer tout

Gestion de sessions

Visual Studio .NET 2003

L'un des défis en matière de développement d'applications pour le Web vient de la difficulté à conserver des informations sur un utilisateur au cours d'une visite, ou session, étant donné que celui-ci navigue de pages en pages au sein de l'application. HTTP est un protocole sans état, ce qui signifie que votre serveur Web traite toute page demandée comme une requête indépendante. Le serveur Web ne retient rien des requêtes formulées au cours des pages précédentes, même si elles ont eu lieu juste avant la requête actuelle. Cette inaptitude à retenir les requêtes précédentes complique beaucoup l'écriture d'applications telles qu'un catalogue en ligne, pour lequel l'application doit pouvoir effectuer le suivi des articles sélectionnés par un utilisateur alors qu'il passe d'une page du catalogue à l'autre.

ASP offre une solution unique au problème de gestion des informations relatives aux sessions. En utilisant l'objet Session ASP et un identificateur d'utilisateur spécial généré par votre serveur, vous pouvez créer des applications intelligentes capables d'identifier chaque visiteur et de recueillir des informations permettant de suivre les préférences ou choix de l'utilisateur.

ASP affecte l'identificateur d'utilisateur à l'aide d'un cookie HTTP, qui est un petit fichier enregistré dans le navigateur de l'utilisateur. Ainsi, si vous créez une application pour des navigateurs ne gérant pas les cookies, ou si vos clients configurent leurs navigateurs pour refuser les cookies, il vous est déconseillé d'utiliser les fonctionnalités de gestion des sessions ASP.

Vous pourrez également écrire des scripts s'exécutant aussi bien au démarrage qu'à la fin d'une application.

Démarrage et fin de sessions

Une session peut démarrer de trois manières :

  • Un nouvel utilisateur sollicite une URL identifiant un fichier .asp dans une application, puis le fichier Global.asa de cette application ajoute une procédure Session_OnStart.
  • Un utilisateur stocke une valeur dans l'objet Session.
  • Un utilisateur demande un fichier .asp dans une application, puis le fichier Global.asa de cette application utilise la balise <OBJECT> pour instancier un objet ayant une étendue session. Consultez Utilisation des composants pour plus d'informations sur l'utilisation de la balise <OBJECT> pour instancier un objet.

Une session se termine automatiquement si l'utilisateur n'a pas demandé ou actualisé la page d'une application, au bout d'une durée déterminée. Cette valeur est de 20 minutes par défaut. Vous pouvez modifier la valeur par défaut d'une application en définissant la propriété Session Timeout sur la feuille de propriétés Application Options, au sein du Gestionnaire des services Internet. Définissez cette valeur en fonction des besoins de votre application Web et de la capacité en mémoire de votre serveur. Exemple : si vous prévoyez que les utilisateurs explorant votre application Web ne s'attarderont que quelques minutes sur chaque page, vous pouvez choisir de réduire de manière significative la valeur par défaut du délai d'expiration d'une session. Un délai trop court peut entraîner l'ouverture simultanée de sessions trop nombreuses et mettre les ressources mémoire de votre serveur à rude épreuve.

Si, pour une raison ou pour une autre, vous souhaitez définir un délai d'expiration plus court que celui défini par défaut dans l'application, vous devez également définir la propriété Timeout de l'objet Session. Exemple : le script ci-dessous définit un délai d'expiration de 5 minutes.

<% Session.Timeout = 5 %>

Vous pouvez également définir un délai d'expiration supérieur à celui défini par défaut, c'est-à-dire celui déterminé par la propriété Temporisation de session..

Vous pouvez encore mettre fin explicitement à une session à l'aide de la méthode Abandon de l'objet Session. Par exemple, vous pouvez proposer un bouton Quitter sur le formulaire, complété par le paramètre ACTION, pointant vers l'URL d'un fichier .asp où se trouve stockée la commande suivante.

<% Session.Abandon %>

À propos des SessionID et des Cookies

La première fois qu'un utilisateur demande un fichier .asp au sein d'une application donnée, ASP génère une SessionID. Un SessionID est un nombre produit par un algorithme complexe, qui identifie de manière unique la session de chaque utilisateur. Au début de chaque nouvelle session, le serveur enregistre le SessionID sous forme de cookie dans le navigateur Web de l'utilisateur.

Le cookie SessionID est comparable à une clé de casier dans la mesure où, lorsque l'utilisateur est en interaction avec une application tout au long d'une session, ASP peut stocker des informations concernant cet utilisateur dans un "casier", sur le serveur. Le cookie SessionID de l'utilisateur, qui est transmis dans l'en-tête de requête HTTP, permet d'accéder à ces informations à la manière d'une clé permettant d'accéder au contenu d'un casier. Chaque fois que ASP est sollicité pour une page, un cookie SessionID est recherché dans l'en-tête de requête HTTP.

Après avoir stocké le cookie SessionID dans le navigateur de l'utilisateur, ASP réutilise le même cookie pour suivre la session, même si l'utilisateur sollicite un autre fichier .asp ou un fichier .asp s'exécutant dans une autre application. De même, si l'utilisateur abandonne volontairement la session ou la laisse arriver à expiration, puis demande un autre fichier .asp, ASP entame une nouvelle session en utilisant le même cookie. La seule occasion où un utilisateur peut recevoir un nouveau cookie SessionID correspond au cas où un administrateur redémarre le serveur, effaçant du même coup les paramètres SessionID stockés en mémoire vive, ou encore lorsque l'utilisateur redémarre le navigateur Web.

En réutilisant le cookie SessionID, ASP minimise le nombre de cookies envoyés à votre navigateur. Si vous décidez en outre que votre application ASP ne nécessite pas de gestion de session, vous pouvez empêcher ASP de suivre les sessions et d'envoyer des cookies SessionID aux utilisateurs.

ASP n'enverra pas de cookies de session dans les cas suivants :

  • Applications où l'état de la session est désactivé.
  • Une page ASP est définie sans session, c'est-à-dire comme une page contenant la balise <%@ EnableSessionState=False %>
  • Page ASP sans session, c'est-à-dire une page contenant la balise <%@ EnableSessionState=False %>. Pour plus d'informations, consultez Pages ASP sans session.

Notez également que les cookies SessionID n'ont pas pour fonction de suivre en permanence les utilisateurs à travers leurs multiples visites sur un site Web. Les informations SessionID stockées dans la mémoire du serveur, peuvent être facilement perdue facilement. Pour suivre les utilisateurs visitant votre application Web aussi longtemps que possible, vous devez créer un moyen d'identification de l'utilisateur en stockant un cookie particulier dans le navigateur de l'utilisateur, puis en enregistrant les informations du cookie vers une base de données. Pour plus d'informations, consultez Utilisation des cookies.

Stockage de données dans l'objet Session

L'objet Session constitue un tableau dynamique et associatif où vous pouvez stocker des informations. Vous pouvez stocker des variables scalaires et des variables objet au sein de l'objet Session.

Pour stocker une variable dans l'objet Session, affectez une valeur à une entrée nommée de l'objet Session. La commande suivante, par exemple, permet de stocker deux nouvelles variables dans l'objet Session :

<% 
Session("FirstName") = "François"
Session("LastName") = "Rhein" 
%>

Pour récupérer des informations provenant de l'objet Session, accédez à l'entrée nommée. Pour afficher, par exemple, la valeur en cours de Session("FirstName") :

Bienvenue <%= Session("FirstName") %>

Vous pouvez stocker les préférences de l'utilisateur dans l'objet Session, puis accéder à ces préférences pour déterminer la page à renvoyer à l'utilisateur. Par exemple, vous pouvez permettre à l'utilisateur de choisir seulement une version texte de votre contenu, dans la première page de l'application, et appliquer ce choix à toutes les pages qui seront visitées par l'utilisateur, au sein de cette application.

<%If Session("ScreenResolution") = "Low" Then %> 
Voici la version texte de la page.
<% Else %> 
Voici la version multimédia de la page.
<% End If %>

Vous pouvez également stocker une instance d'objet dans l'objet Session, même si cela risque d'affecter les performances du serveur.

Gestion de sessions pour des batteries de serveurs Web

Les informations de session ASP sont stockées sur le serveur Web. Le navigateur doit solliciter des pages provenant du même serveur Web afin que les scripts puissent accéder aux informations de session. Dans le cas des batteries de serveurs Web (plusieurs serveurs Web se partagent la responsabilité de répondre aux requêtes de l'utilisateur) les requêtes des utilisateurs ne seront pas toujours dirigées vers le même serveur. À la place, un programme spécifique distribue l'ensemble des requêtes pour l'URL du site, vers le premier serveur disponible. Il s'agit d'un processus appelé équilibrage de la charge. L'équilibrage de la charge rend difficile la conservation des informations de session au sein d'une batterie de serveurs Web.

Pour utiliser la gestion de session ASP sur un site équilibré, vous devez vérifier que toutes les requêtes au sein d'une session utilisateur, sont dirigées vers le même serveur Web. Pour y parvenir, il suffit d'écrire une procédure Session_OnStart utilisant l'objet Response, afin de rediriger le navigateur vers le serveur Web sur lequel la session de l'utilisateur est en cours d'exécution. Si tous les liens des pages de votre application sont relatifs, les futures demandes de pages seront routées vers le même serveur.

Par exemple, si un utilisateur accède à une application en demandant l'URL générale d'un site : http://www.microsoft.com. Le processus d'équilibrage de la charge va diriger la requête vers un serveur spécifique, par exemple, server3.microsoft.com. ASP crée une nouvelle session utilisateur sur ce serveur. Dans la procédure Session_OnStart, le navigateur est redirigé vers le serveur spécifié :

<% Response.Redirect("http://server3.microsoft.com/webapps/firstpage.asp") %>

Le navigateur va demander la page spécifiée, et dès lors, toutes les demandes ultérieures seront acheminées vers le même serveur.

Utilisation des cookies

Un cookie est un jeton que le serveur Web incorpore au navigateur Web d'un utilisateur, dans le but d'identifier cet utilisateur. La prochaine fois que ce navigateur demandera une page, il enverra le cookie reçu de la part du serveur Web. Les cookies permettent d'associer un ensemble d'informations à un utilisateur. Les scripts ASP peuvent à la fois obtenir et définir les valeurs des cookies en utilisant la collection Cookies des objets Response et Request.

Paramétrage des cookies

Pour définir la valeur d'un cookie, utilisez Response.Cookies. Si le cookie n'existe pas déjà, Response.Cookies en crée un nouveau. Par exemple, pour envoyer le nom d'un cookie ("planète") et sa valeur associée ("Mars") au navigateur, utilisez cette commande, qui doit apparaître sur votre page Web avant la balise <HTML> :

<% Response.Cookies("planète")="Mars" %>

Si vous voulez qu'un cookie ne soit utilisé que durant la session en cours de l'utilisateur, il vous suffit simplement d'envoyer ce cookie au navigateur. Cependant, si vous voulez identifier un utilisateur, même après l'arrêt et le redémarrage du navigateur, vous devez obliger le navigateur à stocker le cookie dans un fichier, sur le disque dur de l'ordinateur client. Pour enregistrer le cookie, utilisez l'attribut Expires pour Response.Cookies et choisissez une date quelconque comme date d'expiration :

<%
Response.Cookies("planète") = "Mars" 
Response.Cookies("planète").Expires = "1er janvier 1999" 
%>

Un cookie peut avoir de multiples valeurs ; un tel cookie s'appelle cookie indexé. À chaque valeur du cookie correspond une clé ; vous pouvez définir une valeur particulière pour une clé de cookie. Par exemple :

<% Response.Cookies("planète")("Mars")="MissionSpatiale" %>

Si un cookie existant dispose de valeurs de clé mais que Response.Cookies ne spécifie pas de noms de clé, alors les valeurs de clé existantes sont supprimées. De même, si un cookie existant n'a pas de valeur de clé mais que Response.Cookies spécifie des noms et des valeurs de clé, la valeur antérieure du cookie est supprimée et de nouveaux couples clé-valeur sont créés.

Récupération des cookies

Pour obtenir la valeur d'un cookie, utilisez la collection Request.Cookies. Par exemple, si la requête HTTP de l'utilisateur définit planète=Mars, alors l'instruction suivante récupère la valeur Mars :

<%= Request.Cookies("planète") %>

De même, pour récupérer une valeur de clé d'un cookie indexé, utilisez le nom de la clé. Par exemple, si un utilisateur envoie la requête HTTP suivante :

planète=Mars&Mars=MissionSpatiale

La commande de script suivante renvoie la valeur MissionSpatiale :

<%= Request.Cookies("planète")("Mars") %>

Définition des chemins d'accès des cookies

Chaque cookie stocké par ASP sur le navigateur Web d'un utilisateur contient des informations de type chemin d'accès. Lorsque le navigateur demande un fichier stocké au même emplacement que celui spécifié par le chemin d'accès indiqué dans le cookie, le navigateur transmet automatiquement le cookie au serveur. Par défaut, les chemins d'accès des cookies correspondent au nom de l'application contenant le fichier .asp qui a généré le cookie. Par exemple, si un fichier .asp résidant dans une application appelée UserApplication génère un cookie, à chaque fois que le navigateur Web d'un utilisateur récupère un fichier résidant dans cette application, le navigateur transmet le cookie, en plus de tout autre cookie contenant le chemin /UserApplication.

Pour spécifier le chemin d'un cookie autre que le chemin de l'application par défaut, vous pouvez utiliser l'attribut Chemin de la collection Response.Cookies ASP. Ainsi, le script suivant affecte le chemin AppVentes/Client/Profils/ à un cookie nommé Achats :

<%
Response.Cookies("Achats") = "12" 
Response.Cookies("Achats").Expires = "January 1, 2001" 
Response.Cookies("Achats").Path = "/AppVentes/Client/Profils/"
%>

À chaque fois que le navigateur Web contenant le cookie Achats formule une requête portant sur un fichier résidant à l'emplacement indiqué par le chemin /AppVentes/Client/Profils/ ou dans n'importe lequel des sous-répertoires, le navigateur transmet le cookie au serveur.

De nombreux navigateurs Web, y compris Microsoft Internet Explorer version 4.0 et Netscape, respectent la casse du chemin d'accès du cookie. Cela signifie que si le chemin d'accès d'un fichier demandé est en minuscules et celui du cookie stocké en majuscules, le navigateur n'envoie pas le cookie au serveur. Par exemple, pour ASP, les répertoires virtuels /VOYAGE et /voyage correspondent à une seule et même application ASP, alors qu'un navigateur qui respecte la casse d'une URL fait la différence entre les applications /VOYAGE et /voyage. Vérifiez que toutes les URL des fichiers .asp ont bien la même casse pour que le navigateur de l'utilisateur puisse transmette les cookies stockés.

Vous pouvez, si vous le souhaitez, utiliser l'instruction ci-dessous pour définir le chemin du cookie de telle sorte que le navigateur Web de l'utilisateur transmette un cookie à chaque fois que le navigateur réclame un fichier à votre serveur, quels que soient l'application et le chemin :

Response.Cookies("Purchases").Path = "/"

Vous remarquerez que le fait de transmettre des cookies au serveur sans faire de distinction entre les applications peut poser un problème de sécurité lorsque les cookies contiennent des informations confidentielles qui ne doivent pas être accessibles en dehors d'une application spécifique.

Préservation de l'état sans cookies

Les navigateurs ne gèrent pas tous les cookies. Même sur les navigateurs acceptant les cookies, certains utilisateurs préfèrent désactiver la prise en charge des cookies. Si votre application doit répondre à des navigateurs ne gérant pas les cookies, vous ne pouvez utiliser la gestion de session ASP.

Si vous n'utilisez pas la gestion de session ASP, vous devez écrire votre propre mécanisme de transfert des informations d'une page à l'autre de votre application. Il existe deux façons d'y parvenir :

  • En ajoutant des paramètres à la chaîne de requête d'une URL. Par exemple :
    http://MonServeu/MonApp/start.asp?name=François
    

    Néanmoins, certains navigateurs rejetteront tous les paramètres explicites transitant dans une chaîne de requête, si la méthode GET est utilisée pour envoyer un formulaire.

  • En ajoutant des valeurs cachées à un formulaire. Ainsi, le formulaire HTML suivant contient un contrôle caché qui n'apparaît pas sur le formulaire en cours et reste invisible dans le navigateur de l'utilisateur. Le formulaire transfère une valeur d'identification de l'utilisateur, en plus des informations fournies par cet utilisateur, grâce à la méthode HTTP POST.
    <FORM METHOD="POST" ACTION="/scripts/inform.asp">
    <INPUT TYPE="text" NAME="city" VALUE="">
    <INPUT TYPE="text" NAME="country" VALUE ="">
    <INPUT TYPE="hidden" NAME="userid" VALUE= <%=UserIDNum(i) %>
    <INPUT TYPE="submit" VALUE="Entrée">
    

    Cette méthode nécessite que toutes les destinations de liens transférant des informations sur l'utilisateur soient codés en tant que formulaires HTML.

Si vous n'utilisez pas de gestion de session ASP, désactivez la gestion de session pour votre application. Lorsque les sessions sont activées, ASP envoie un cookie SessionID à chaque navigateur demandant une page. Pour mettre fin à la gestion de session, désactivez la case à cocher Activer l'état de session dans la page de propriétés Application Options, dans le Gestionnaire des services Internet.

Pages ASP sans session

ASP est assez souple pour vous permettre de créer des pages sans session, que vous pouvez utiliser pour retarder la création de session, jusqu'à ce qu'un utilisateur visite une page ASP nécessitant un suivi de session.

Les pages sans session ne peuvent pas réaliser les actions suivantes :

  • Exécuter des procédures Session_OnStart.
  • Envoyer des cookies d'identification de session.
  • Créer des objets Session.
  • Accéder à des objets session incorporés ou ayant une étendue session, créés à l'aide de la balise <OBJECT>.
  • Effectuer des exécutions en série de plusieurs requêtes de session.

Pour configurer un fichier .asp sans session, procédez comme suit :

<%@ EnableSessionState=False %>

Ce script doit correspondre à la première ligne du fichier .asp et précéder tous les autres scripts. Lorsque cette balise est omise, le suivi de session est activé par défaut.

Les pages ASP sans session améliorent bien souvent le délai de réponse du serveur, en éliminant les activités de session coûteuses en temps. Prenez, par exemple, le cas d'une page ASP contenant deux cadres HTML, cadre 1 et cadre 2, tous deux dans un même cadre. Cadre 1 contient un fichier .asp qui exécute un script complexe, tandis que cadre 2 contient un simple fichier .html. Étant donné que ASP exécute les requêtes de session dans un ordre séquentiel ou en série, vous ne pourrez voir le contenu du cadre 2 avant que le script du cadre 1 ne soit exécuté. Cependant, si vous faites du fichier .asp du cadre 1 un fichier sans session, les requêtes ASP ne seront plus mises en série et le navigateur renvoie le contenu du cadre 2 avant la fin de l'exécution du cadre 1.

Malheureusement, la façon dont sont traitées les requêtes multiples pour différents cadres dépend surtout de la configuration du navigateur de l'utilisateur. Certains navigateurs peuvent mettre en série les requêtes ASP en dépit d'une configuration sans session de vos fichiers .asp.

Dernière mise à jour le dimanche 21 novembre 1999



Afficher:
© 2014 Microsoft