Série de conférences ASP (19) Gestion des sessions
Auteur：Eve Cole
Date de mise à jour：2009-05-30 19:58:38
L'un des défis du développement réussi d'applications Web consiste à conserver les informations utilisateur pendant que l'utilisateur passe d'une page à l'autre dans une application au cours d'une visite ou d'une session utilisateur. HTTP est un protocole sans état, ce qui signifie que le serveur Web traite chaque accès à une page comme un accès sans rapport ; le serveur ne conserve aucune information sur l'accès précédent, même si l'accès se produit quelques jours après l'accès en cours. il y a. Ce manque de mémoire des visites précédentes rend difficile l'écriture d'applications telles que des catalogues en ligne, qui peuvent avoir besoin de garder une trace des éléments de catalogue qu'un utilisateur a sélectionnés en naviguant entre différentes pages du catalogue.
ASP fournit une solution unique pour gérer les problèmes d'informations de session. À l'aide de l'objet Session ASP et d'un ID utilisateur spécial généré par votre serveur, vous pouvez créer une application intelligente capable d'identifier chaque utilisateur entrant et de collecter des informations utilisées par l'application pour suivre les préférences ou les sélections de contenu de l'utilisateur.
ASP définit l'ID utilisateur via des cookies HTTP. Les cookies HTTP sont de petits fichiers stockés sur le navigateur de l'utilisateur. Par conséquent, si vous créez une application pour un navigateur qui ne prend pas en charge les cookies, ou si vos clients ont configuré leur navigateur pour ne pas accepter les cookies, n'utilisez pas la fonctionnalité de gestion de session d'ASP.
Vous pouvez également écrire des scripts qui s'exécutent au démarrage ou à la fin de l'application.
Démarrage et fin de sessions Les sessions peuvent être démarrées de trois manières :
Un nouvel utilisateur demande l'accès à une URL qui identifie un fichier .asp dans une application dont le fichier Global.asa contient la procédure Session_OnStart.
L'utilisateur stocke une valeur dans l'objet Session.
L'utilisateur demande le fichier .asp d'une application et le fichier Global.asa de l'application utilise la balise <OBJECT> pour créer une instance de l'objet avec une portée de session.
Si l'utilisateur ne demande ou n'actualise aucune page de l'application pendant une période de temps spécifiée, la session se terminera automatiquement. La valeur par défaut pour cette période est de 20 minutes. Vous pouvez modifier le paramètre de délai d'expiration par défaut de l'application en définissant la propriété « Délai d'expiration de la session » dans la page de propriétés « Options de l'application » dans le Gestionnaire des services Internet. Cette valeur doit être définie en fonction des exigences de votre application Web et de l'espace mémoire du serveur. Par exemple, si vous souhaitez que les utilisateurs parcourant votre application Web restent sur chaque page pendant quelques minutes seulement, vous devez raccourcir la valeur du délai d'expiration de session par défaut. Une valeur de délai d'expiration de session trop longue entraînera un trop grand nombre de sessions ouvertes qui épuiseront les ressources mémoire de votre serveur.
Pour une session spécifique, si vous souhaitez définir une valeur de délai d'expiration inférieure à la valeur de délai d'expiration par défaut, vous pouvez définir la propriété Timeout de l'objet Session. Par exemple, le script suivant définit la valeur du délai d'attente sur 5 minutes.
<%Session.Timeout = 5%>
Vous pouvez également définir une valeur de délai d'expiration supérieure au paramètre par défaut. La propriété Session.Timeout détermine la valeur du délai d'expiration.
Vous pouvez également mettre fin explicitement à une session via la méthode Abandon de l'objet Session. Par exemple, pour fournir un bouton Quitter dans un tableau, définissez le paramètre ACTION du bouton sur l'URL d'un fichier .asp contenant la commande suivante.
<% Session.Abandon %>
À propos de l'ID de session et des cookies
Lorsqu'un utilisateur demande pour la première fois un fichier .asp dans une application donnée, ASP génère un SessionID. SessionID est un numéro généré par un algorithme complexe qui identifie de manière unique chaque session utilisateur. Au début d'une nouvelle session, le serveur stocke l'ID de session sous forme de cookie dans le navigateur Web de l'utilisateur.
Un SessionID ressemble beaucoup à une clé dans la mesure où ASP peut stocker les informations utilisateur dans un « coffre-fort » sur le serveur lorsque l'utilisateur interagit avec l'application au cours d'une session. Tout comme une clé peut être utilisée pour accéder aux éléments d'un coffre-fort, le contenu du « coffre-fort » est accessible via le cookie SessionID de l'utilisateur envoyé dans l'en-tête de la requête HTTP. Chaque fois qu'ASP reçoit une requête de page, il vérifie l'en-tête de la requête HTTP pour obtenir le cookie SessionID.
Une fois le cookie SessionID stocké dans le navigateur de l'utilisateur, ASP réutilise toujours le cookie pour suivre la session même si l'utilisateur demande un autre fichier .asp ou demande un fichier .asp exécuté dans une autre application. De même, si l'utilisateur abandonne intentionnellement la session ou laisse la session expirer, puis demande un autre fichier .asp, ASP démarrera une nouvelle session avec le même cookie. Ce n'est que lorsque l'administrateur du serveur redémarre le serveur ou que l'utilisateur redémarre le navigateur Web que les paramètres SessionID stockés dans la mémoire seront effacés et que l'utilisateur recevra un nouveau cookie SessionID.
En réutilisant le cookie SessionID, ASP minimise le nombre de cookies envoyés au navigateur de l'utilisateur. Alternativement, si vous décidez 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 ID de session aux utilisateurs.
ASP n'envoie pas de cookies de session dans les circonstances suivantes :
L'état de session de l'application est désactivé.
Une page ASP est définie comme étant sans session, c'est-à-dire qu'elle contient la balise <%@ EnableSessionState=False %>.
Veuillez noter que le cookie SessionID ne fournit pas une méthode permanente de suivi d'un utilisateur lors de plusieurs visites sur un site Web. Les informations SessionID stockées dans la mémoire du serveur peuvent facilement être perdues. Si vous souhaitez suivre les utilisateurs qui visitent votre application Web au fil du temps, vous devez créer une identité d'utilisateur en stockant un cookie spécial dans le navigateur Web de l'utilisateur et en enregistrant les informations du cookie dans une base de données.
Stocker les données dans l'objet Session
L'objet Session fournit un tableau associatif dynamique dans lequel les informations peuvent être stockées. Vous pouvez stocker des variables numériques et des variables d'objet dans des objets Session.
Les variables peuvent être stockées dans un objet Session en attribuant des valeurs aux éléments nommés dans l'objet Session. Par exemple, la commande suivante stocke deux nouvelles variables dans l'objet Session :
<%
Session("Prénom") = "Jeff"
Session("Nom") = "Smith"
%>
Des informations peuvent être obtenues à partir de l'objet Session en accédant à cet élément nommé. Par exemple, affichez la valeur actuelle de Session("FirstName") :
Bienvenue <%= Session("FirstName") %>
Vous pouvez stocker les préférences de l'utilisateur dans l'objet Session, puis accéder aux préférences pour décider quelle page envoyer à l'utilisateur. Par exemple, vous pouvez autoriser les utilisateurs à spécifier une version texte uniquement du contenu sur la première page de votre application et à appliquer cette sélection à toutes les pages suivantes de l'application que l'utilisateur visite.
<% Si Session("ScreenResolution") = "Faible" Then %>
Ceci est la version texte de la page.
<%Else%>
Ceci est la version multimédia de la page.
<% Fin Si %>
Vous pouvez également stocker une instance d'objet dans l'objet Session, mais cela affectera les performances du serveur.
Gérer les sessions de la ferme Web
Les informations de session ASP sont stockées sur le serveur Web. Le navigateur doit demander une page au serveur Web pour obtenir le script utilisé pour accéder aux informations de session. Dans une ferme Web (où de nombreux serveurs Web partagent la responsabilité de répondre aux demandes des utilisateurs), les demandes des utilisateurs ne sont pas toujours acheminées vers le même serveur, mais plutôt vers l'URL par un logiciel spécial appelé processus « d'équilibrage de charge » de l'application du site. est attribué à n’importe quel serveur gratuit. Le processus d'équilibrage de charge rend plus difficile la préservation des informations de session dans Web Farm.
Afin d'utiliser la gestion de session ASP sur un site à charge équilibrée, vous devez vous assurer que toutes les demandes de session utilisateur sont dirigées vers le même serveur Web. Une approche consiste à écrire une procédure Session_OnStart qui utilise un objet Response pour rediriger le navigateur vers le serveur Web exécutant la session de l'utilisateur. Si tous les liens dans les pages de votre application sont relatifs, alors toutes les futures demandes d'une page seront acheminées vers le même serveur.
Par exemple, un utilisateur souhaite accéder à une application en demandant l'URL universelle d'un site : http://www.microsoft.com. Le processus d'équilibrage de charge achemine les requêtes vers le serveur server3.microsoft.com. ASP a généré une nouvelle session utilisateur sur ce serveur. Pendant le processus Session_OnStart, le navigateur est redirigé vers le serveur spécifié :
<% Response.Redirect("http://server3.microsoft.com/webapps/firstpage.asp") %>
Le navigateur demandera la page spécifiée et toutes les demandes futures seront acheminées vers le même serveur.
Utiliser des cookies
Un cookie est un jeton que le serveur Web intègre dans le navigateur Web de l'utilisateur pour représenter l'utilisateur. La prochaine fois que le même navigateur demandera une page, il enverra le cookie reçu du serveur Web. Un cookie permet d'associer un ensemble d'informations à un utilisateur. Les scripts ASP utilisent la collection Cookies d'objets Response et Request pour obtenir et définir les valeurs des cookies.
Définir des cookies
Pour définir la valeur d'un cookie, utilisez Response.Cookies. Si le cookie n'existe pas, Response.Cookies créera un nouveau cookie. Par exemple, pour envoyer un nom de cookie (« planète ») avec une valeur associée (« Mars ») au navigateur, utilisez les commandes suivantes, qui doivent apparaître avant la balise <HTML> de votre page Web :
<% Response.Cookies("planète")="Mars" %>
Si vous souhaitez que le cookie soit utilisé uniquement pendant la session utilisateur en cours, envoyez simplement le cookie au navigateur. Toutefois, si vous souhaitez reconnaître l'utilisateur après avoir fermé ou redémarré le navigateur, vous devez forcer le navigateur à stocker le cookie sur le disque dur de l'ordinateur. Pour enregistrer un cookie, utilisez la propriété Expires de Response.Cookies et définissez la date sur un jour dans le futur :
<%
Réponse.Cookies("planète") = "Mars"
Response.Cookies("planète").Expires = "1er janvier 1999"
%>
Un cookie peut avoir plusieurs valeurs ; un tel cookie est appelé cookie indexé. Chaque valeur de cookie se voit attribuer un mot-clé ; vous pouvez définir la valeur d'un mot-clé de cookie spécifique. Par exemple:
<% Response.Cookies("planète"))("Mars")="SpaceMissions" %>
Si un cookie existant a une valeur de mot-clé mais que Response.Cookies ne spécifie pas le nom d'un mot-clé, la valeur du mot-clé sera supprimée. De même, si un cookie existant n'a pas de valeur de mot-clé mais que Response.Cookies spécifie le nom et la valeur du mot-clé, la valeur du cookie existant sera supprimée et une nouvelle paire clé-valeur sera générée.
Obtenez 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, l'instruction suivante obtiendra la valeur Mars :
<%= Request.Cookies("planète") %>
De même, pour obtenir une valeur de mot-clé à partir d'un cookie indexé, utilisez le nom du mot-clé. Par exemple, si l'utilisateur effectue la requête HTTP suivante :
planète = Mars et Mars = Missions spatiales
Le script suivant renverra la valeur SpaceMissions :
<%= Request.Cookies("planète"))("Mars") %>
Définition du chemin du cookie Chaque cookie stocké par ASP dans le navigateur Web de l'utilisateur contient des informations sur le chemin. Lorsque le navigateur demande un fichier dont l'emplacement est le même que le chemin spécifié dans le cookie, le navigateur transmet automatiquement le cookie au serveur. Par défaut, le chemin du cookie correspond au nom de l'application qui contient le fichier .asp qui a initialement généré le cookie. Par exemple, si un fichier .asp dans une application nommée UserApplication génère un cookie, chaque fois que le navigateur Web de l'utilisateur récupère le fichier dans cette application, le navigateur Ce cookie est également transmis au serveur.
Pour déclarer un chemin pour un cookie différent du chemin d'accès par défaut de l'application, utilisez la propriété Path de la collection Response.Cookies d'ASP. Par exemple, le script suivant attribue le chemin SalesApp/Customer/Profiles/ à un cookie nommé Achats :
<%
Réponse.Cookies("Achats") = "12"
Response.Cookies("Achats").Expires = "1er janvier 2001"
Response.Cookies("Achats").Path = "/SalesApp/Customer/Profiles/"
%>
Chaque fois qu'un navigateur Web contenant le cookie Achats demande un fichier situé dans le chemin /SalesApp/Customer/Profiles/ ou dans ses sous-répertoires, le navigateur transmet le cookie au serveur.
De nombreux navigateurs Web, notamment les navigateurs Microsoft Internet Explorer 4.0 et Netscape, préservent la casse des chemins de cookies. Autrement dit, si le cas d'un fichier demandé est différent du chemin de cookie réservé, le navigateur ne transmettra pas le cookie au serveur. Par exemple, pour ASP, les répertoires virtuels /TRAVEL et /travel sont la même application ASP, mais pour les navigateurs qui préservent la casse des URL, /TRAVEL et /travel sont deux applications différentes. Vous devez vous assurer que toutes les URL du fichier .asp ont la même casse pour garantir que le navigateur de l'utilisateur peut transférer le cookie stocké.
Si vous le souhaitez, vous pouvez utiliser l'instruction suivante pour définir le chemin du cookie afin que le cookie soit transmis chaque fois que le navigateur Web de l'utilisateur demande un fichier à votre serveur, quel que soit l'application ou le chemin :
Response.Cookies("Achats").Path = "/"
Veuillez toutefois noter que l'envoi de cookies au serveur sans distinction entre les applications peut créer des problèmes de sécurité si le cookie contient des informations sensibles qui ne devraient pas être accessibles par des programmes autres que l'application désignée.
Préserver l'état sans utiliser de cookies Tous les navigateurs ne prennent pas en charge les cookies. Même lorsqu'ils utilisent un navigateur prenant en charge les cookies, certains utilisateurs peuvent préférer désactiver la prise en charge des cookies. Si votre application doit répondre à des navigateurs qui ne supportent pas les cookies, vous devez utiliser la gestion de session ASP.
Si vous n'utilisez pas la gestion de session ASP, vous devez écrire votre propre mécanisme pour transmettre les informations entre les pages de votre application. Il existe deux manières générales d'accomplir cette tâche :
Ajoutez des paramètres à la chaîne de requête de l'URL. Par exemple:
http://MonServeur/MonApp/start.asp?name=Jeff
Cependant, certains navigateurs ignoreront les paramètres explicites transmis dans la chaîne de requête lorsque le formulaire est soumis avec la méthode GET.
Ajoutez des valeurs cachées au tableau. Par exemple, le tableau HTML suivant contient un contrôle implicite. Ce contrôle n'apparaît pas dans le formulaire réel et n'est pas visible par le navigateur Web de l'utilisateur. Grâce à la méthode HTTP POST, le formulaire transmet l'identifiant de l'utilisateur en plus des informations fournies par l'utilisateur.
<FORM METHOD="POST" ACTION="/scripts/inform.asp">
<INPUT TYPE="texte" NAME="ville" VALUE="">
<INPUT TYPE="texte" NAME="pays" VALUE="">
<INPUT TYPE="hidden" NAME="userid" VALUE= <%=UserIDNum(i) %>
<INPUT TYPE="soumettre" VALUE="Entrée">
Cette méthode nécessite que toutes les cibles de lien qui transfèrent les informations utilisateur soient codées sous forme de tableaux HTML.
Si vous n'utilisez pas actuellement la gestion de session ASP, désactivez la prise en charge de session pour votre application. Lorsqu'une session est activée, ASP envoie le cookie SessionID à chaque navigateur qui demande une page ASP. Pour désactiver la prise en charge de session, décochez la case Activer l'état de session dans la page de propriétés Options d'application dans le Gestionnaire des services Internet.
Page ASP sans session
ASP offre également la possibilité de créer des pages sans session, que vous pouvez utiliser pour différer la création de session jusqu'à ce que l'utilisateur accède à une page ASP nécessitant un suivi de session.
Les pages sans session n'exécutent pas les fonctions suivantes :
Exécutez la procédure Session_OnStart.
Envoyer un cookie d'identification de session.
Créez un objet Session.
Accédez aux objets de session intégrés ou aux objets de portée de session créés avec la balise <OBJECT>.
Exécuté séquentiellement avec d’autres demandes de session.
Pour configurer .asp pour qu'il soit sans session, utilisez l'instruction suivante :
<%@ EnableSessionState=False %>
Vous devez placer ce script sur la première ligne du fichier .asp, avant les autres scripts. Par défaut, si cet indicateur est omis, le suivi de session est activé.
Les pages ASP sans session améliorent les performances de réponse du serveur en éliminant les opérations de session potentiellement chronophages. Par exemple, considérons la situation suivante : une page ASP contient deux cadres HTML, Frame 1 et Frame 2, dans un ensemble de cadres. Le cadre 1 contient un fichier .asp qui exécute un script complexe, tandis que le cadre 2 contient un simple fichier .html. Étant donné qu'ASP exécute les demandes de session de manière séquentielle (c'est-à-dire en série), vous ne verrez pas le contenu de l'image 2 tant que le script de l'image 1 n'est pas exécuté. Toutefois, si vous définissez l'image 1 sur sans session, la requête ASP n'est plus traitée en série et le navigateur n'a pas besoin d'attendre la fin de l'exécution du contenu de l'image 1 avant de pouvoir traiter le contenu de l'image 2.
Cependant, la manière dont plusieurs requêtes pour différentes trames sont traitées dépend en fin de compte de la configuration du navigateur Web de l'utilisateur. Certains navigateurs Web peuvent ignorer la configuration sans session de votre fichier .asp et continuer à traiter les requêtes en série.
