Exporter (0) Imprimer
Développer tout
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Notions de base concernant les cookies dans ASP.NET

Visual Studio .NET 2003

Mike Pope
Éducation de l'utilisateur Visual Basic
Microsoft Corporation
Janvier 2003

Résumé : Cet article explique comment lire et écrire des cookies HTTP dans une application Web ASP.NET à l'aide de Visual Basic.

S'applique à :

  • ASP.NET
  • Microsoft® Visual Studio® .NET
  • Web Forms

Niveau : programmeur Web débutant

Sommaire


Introduction

Les cookies constituent un moyen pratique de stockage des informations spécifiques à l'utilisateur dans les applications Web. Par exemple, lorsqu'un utilisateur visite votre site, vous pouvez utiliser des cookies pour stocker les préférences de celui-ci ou d'autres informations. Lorsque l'utilisateur revient sur votre site Web, l'application peut récupérer les informations stockées précédemment.

Cet article donne une vue d'ensemble de l'utilisation des cookies dans des applications ASP.NET. J'aborderai les mécanismes de l'utilisation des cookies dans ASP.NET, tels que leur écriture et leur lecture un peu plus tard. Au fil de ce document, je vous expliquerai les diverses fonctions et particularités (éventuelles) des cookies, ainsi que leur prise en charge dans ASP.NET.

Qu'est-ce qu'un cookie ?

Un cookie est un petit texte accompagnant des requêtes et des pages échangées entre le serveur Web et le navigateur. Le cookie contient des informations que l'application Web peut lire à chaque fois que l'utilisateur visite un site.

Imaginez que lorsque les utilisateurs demandent une page de votre site, www.contoso.com, votre application envoie non seulement une page, mais également un cookie contenant la date et l'heure. Lorsque le navigateur de l'utilisateur reçoit la page, il reçoit également ce cookie qu'il stocke dans un dossier sur le disque dur de l'utilisateur.

Plus tard, lorsque l'utilisateur demande à nouveau une page de votre site et lorsqu'il entre l'URL www.contoso.com, le navigateur recherche sur le disque dur local un cookie associé à cette URL. Si ce cookie existe, le navigateur envoie ce dernier à votre site avec la demande de page. Votre application peut alors déterminer la date et l'heure de la dernière visite de cet utilisateur sur le site. Vous pouvez utiliser ces informations pour faire apparaître un message à l'utilisateur, vérifier une date d'expiration ou exécuter toute autre fonction utile.

Les cookies sont associés à un site Web, et non à une page spécifique, ainsi le navigateur et le serveur échangeront les informations du cookie www.contoso.com quelle que soit la page que l'utilisateur demande sur votre site. Au fur et à mesure que l'utilisateur visite différents sites, chacun d'entre eux envoie également un cookie au navigateur de l'utilisateur, qui les stocke séparément.

C'est le principe de base du fonctionnement des cookies. Mais quelle est leur utilité ? Par essence, les cookies aident les sites Web à stocker des informations relatives à leurs visiteurs. De façon plus générale, ils permettent de conserver une sorte de continuité dans une application Web (en exécutant ce que l'on appelle de façon formelle la gestion des états). En dehors de la brève période au cours de laquelle ils échangent réellement des informations, le navigateur et le serveur Web sont déconnectés. Chaque demande effectuée auprès d'un serveur Web est traitée indépendamment des autres. Toutefois, il est très souvent utile pour le serveur Web de vous identifier lorsque vous demandez une page. Par exemple, le serveur Web d'un site de vente en ligne garde une trace de chacun des acheteurs de façon à gérer leurs paniers, ainsi que d'autres informations spécifiques à ces utilisateurs. Un cookie agit par conséquent comme une sorte de carte d'appel, présentant une identification pertinente qui indique à une application comme procéder.

Les cookies sont utilisés à diverses fins, visant toutes à aider les sites Web à se souvenir de vous. Par exemple, un site réalisant un sondage peut utiliser un cookie simplement sous forme de valeur booléenne pour indiquer que votre navigateur a déjà participé au vote de sorte que vous ne puissiez pas voter deux fois. Un site nécessitant une connexion de votre part peut utiliser un cookie lui indiquant que vous vous êtes déjà connecté et que vous n'avez donc pas besoin de saisir à nouveau les informations relatives à votre authentification.

Pour obtenir davantage d'informations sur les cookies, je vous recommande l'article How Internet Cookies Work Lien non Microsoft Site en anglais sur le site Web Verizon. L'auteur y décrit les cookies en détail, ainsi que la façon dont ils sont échangés entre le navigateur et le serveur. Il fournit également un bon résumé des problèmes de confidentialité liés aux cookies.

Restrictions inhérentes aux cookies

Avant d'aborder réellement les mécanismes de l'utilisation des cookies, je souhaiterai vous indiquer quelques restrictions inhérentes à ces derniers. La plupart des navigateurs supportent des cookies de 4 096 octets maximum. Ceci représente beaucoup d'espace pour stocker quelques valeurs sur les ordinateurs des utilisateurs, mais il est peu probable que vous essayez de stocker un ensemble de données ou d'autres données potentiellement encombrantes dans un cookie. Sur le plan pratique, vous n'aurez probablement pas besoin de stocker une grande collection d'informations utilisateur dans un cookie. Vous y stockerez plutôt un numéro d'utilisateur ou tout autre identificateur. Ainsi, lorsque l'utilisateur visitera à nouveau votre site, vous utiliserez son ID d'utilisateur pour rechercher les détails le concernant dans une base de données. (Mais reportez-vous à la section Cookies et sécurité pour en savoir plus sur les inconvénients liés au stockage des informations utilisateur.)

Les navigateurs imposent également des restrictions concernant le nombre de cookies que votre site peut stocker sur l'ordinateur de l'utilisateur. La plupart d'entre eux autorisent 20 cookies par site, si vous essayez d'en stocker plus, les anciens cookies sont supprimés. Certains navigateurs imposent une limite absolue, en général 300, sur le nombre total de cookies qu'ils acceptent pour l'ensemble des sites.

Une autre limite inhérente aux cookies et à laquelle vous risquez de vous trouver confronté est que les utilisateurs peuvent configurer leur navigateur de sorte qu'il refuse les cookies. Vous ne pouvez rien face à ce problème si ce n'est éviter les cookies et utiliser un autre mécanisme pour stocker les informations spécifiques à l'utilisateur. L'état de session est une méthode courante pour stocker des informations concernant l'utilisateur, mais elle dépend également des cookies, comme je l'expliquerai un peu plus tard dans la section Cookies et état de session.

Remarque Pour obtenir davantage d'informations concernant la gestion des états et les options relatives à la sauvegarde des informations dans une application Web, reportez-vous aux articles Introduction to Web Forms State Management Lien non MSDN France Site en anglais et http://msdn.microsoft.com/library/en-us/vbcon/html/vbconChoosingServerStateOption.asp State Management Recommendations Lien non MSDN France Site en anglais.

La principale leçon à retenir est probablement que malgré l'aspect pratique des cookies dans votre application, cette dernière ne doit pas être dépendante de sa capacité ou non à stocker des cookies. Utilisez ces derniers pour des fonctions non essentielles, ne les utilisez pas pour supporter des fonctions critiques. Si votre application doit utiliser des cookies, vous pouvez réaliser un test pour voir si le navigateur les accepte. Je décris comment exécuter ce test dans la section Comment vérifier si un navigateur accepte les cookies un peu plus loin dans ce document.

Écriture des cookies

Vous pouvez écrire des données dans un cookie à l'aide de la propriété Response Lien non MSDN France Site en anglais de la page, qui expose un objet vous permettant d'ajouter des informations renvoyées au navigateur par la page. Cet objet Response prend en charge une collection nommée Cookies Lien non MSDN France Site en anglais, à laquelle vous ajoutez les cookies que vous souhaitez inscrire dans le navigateur.

Remarque L'objet Response et l'objet Request, dont je parlerai d'ici peu, sont des propriétés de la page qui contiennent, respectivement, des instances des classes HttpResponse Lien non MSDN France Site en anglais et http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemWebHttpRequestClassTopic.asp HttpRequest Lien non MSDN France Site en anglais. Pour trouver des informations dans la documentation à propos de Response et Request, effectuez une recherche sur HttpResponse et HttpRequest.

Lorsque vous créez un cookie, vous spécifiez plusieurs valeurs. Commencez par spécifier le nom du cookie et la valeur que vous voulez y stocker. Vous pouvez créer plusieurs cookies, chaque cookie devant posséder un nom unique de façon à ce que vous puissiez l'identifier la prochaine fois que vous le lirez. (Les cookies sont stockés par nom, ainsi si vous créez deux cookies portant le même nom, le deuxième écrase le premier.)

Il vous faut également spécifier la date et l'heure d'expiration du cookie. Les cookies sont normalement écrits sur le disque de l'utilisateur où ils peuvent potentiellement rester à jamais. Vous pouvez donc spécifier une date et une heure auxquelles le cookie expirera. Lorsque l'utilisateur visitera à nouveau votre site, le navigateur commencera par examiner la collection de cookies relative à votre site. Si un cookie a expiré, le navigateur ne l'envoie pas au serveur avec la demande de page, mais il le supprime. (Il est possible que votre site ait écrit de nombreux cookies sur l'ordinateur de l'utilisateur, chaque cookie peut avoir une date et une heure d'expiration distincte.) Notez que le navigateur est responsable de la gestion des cookies sur le disque dur, ce qui affecte l'utilisation des cookies dans votre application, ainsi que je vous l'expliquerai un peu plus loin dans cet article.

Quelle doit être la durée de la période d'expiration d'un cookie ? Tout dépend de la raison pour laquelle vous utilisez ce cookie, ou en d'autres termes, de la durée pendant laquelle votre application considère la valeur du cookie comme valide. Si vous utilisez des cookies pour compter les visiteurs de votre site, vous pouvez décider de définir une durée d'expiration d'un an à compter d'aujourd'hui en vous basant sur le principe que si une personne n'est pas revenue sur votre site au bout d'un an, vous pouvez le considérer comme un nouveau visiteur. En revanche, si vous utilisez des cookies pour stocker les préférences des utilisateurs, vous pouvez définir la durée d'expiration de façon à ce qu'elle n'expire jamais en réalité (en définissant par ex. une durée de 50 ans), car il est fastidieux pour un utilisateur d'avoir à redéfinir périodiquement ses préférences. Vous pouvez écrire un cookie qui expire en l'espace de quelques secondes ou de quelques minutes. Dans la section Comment vérifier si un navigateur accepte les cookies, je décris un exemple de création de cookie dont la durée de vie pratique est mesurée en secondes.

Remarque N'oubliez pas que les utilisateurs peuvent supprimer les cookies de leur ordinateur à tout moment. Même si vous stockez des cookies avec des périodes d'expiration longues, un utilisateur peut décider de supprimer tous les cookies, supprimant ainsi tous les paramétrages qui y sont stockés.

Si vous ne définissez pas l'expiration du cookie, ce dernier est créé, mais il n'est pas stocké sur le disque dur de l'utilisateur. Au lieu de cela, il est conservé en tant que partie intégrante des informations de session de l'utilisateur. Lorsque l'utilisateur ferme le navigateur ou lorsque la session expire, le cookie est supprimé. Un tel cookie non persistant est pratique pour les informations qui doivent être stockées pour une courte durée ou qui, pour des raisons de sécurité, ne doivent pas être écrites sur le disque de l'ordinateur client. Par exemple, les cookies non persistants sont utiles si l'utilisateur travaille sur un ordinateur public sur le disque duquel vous ne souhaitez pas écrire de cookies.

Vous pouvez ajouter des cookies à la collection Response.Cookies de différentes façons. L'exemple suivant illustre deux méthodes permettant d'accomplir cette tâche :

Response.Cookies("userName").Value = "mike"
Response.Cookies("userName").Expires = DateTime.Now.AddDays(1)

Dim aCookie As New HttpCookie("lastVisit")
aCookie.Value = DateTime.Now.ToString
aCookie.Expires = DateTime.Now.AddDays(1)
Response.Cookies.Add(aCookie)

Cet exemple ajoute deux cookies à la collection Cookies, l'un appelé « userName » et l'autre « lastVisit ». Pour le premier cookie, j'ai directement défini les valeurs de la collection Response.Cookies. Vous pouvez utiliser cette méthode pour ajouter des valeurs à la collection, car Response.Cookies dérive d'une collection spécialisée du type NameObjectCollectionBase Lien non MSDN France Site en anglais.

Pour le second cookie, j'ai créé une instance de l'objet cookie (type HttpCookie Lien non MSDN France Site en anglais), défini ses propriétés, puis je l'ai ajouté à la collection Response.Cookies via la méthode Add. Lorsque vous instanciez un objet HttpCookie, vous devez transmettre le nom de cookie en tant que partie intégrante du constructeur.

Ces deux exemples accomplissent la même tâche, c'est-à-dire l'écriture d'un cookie dans le navigateur. La méthode à utiliser dépend en grande partie de vos préférences personnelles. Il est possible que vous constatiez que la seconde méthode permet de définir un peu plus facilement les propriétés du cookie, mais comme vous le voyez, ces différences sont minimes.

Dans les deux méthodes, la valeur d'expiration doit être du type DateTime. Toutefois, la valeur « lastVisited » est également une valeur date/heure. En pareil cas, toutefois, j'ai converti la valeur date/heure en une chaîne. Toute valeur stockée dans un cookie est finalement stockée sous forme de chaîne.

Jetons un coup d'œil à vos cookies

Il vous semblera peut-être pratique de visualiser l'effet de la création des cookies. Il est facile d'observer des cookies une fois que vous les avez trouvés, car il s'agit de fichiers texte après tout. Les différents navigateurs stockent les cookies de différentes façons. Je décrirai plus tard comment Internet Explorer stocke des cookies ; si vous utilisez un navigateur différent, vérifiez l'Aide de ce dernier pour savoir comment il gère les cookies.

Une façon pratique d'afficher les cookies est d'effectuer une recherche via Internet Explorer. Dans Internet Explorer, choisissez Options Internet dans le menu Outils. Dans l'onglet Général, sélectionnez Paramètres, puis cliquez sur Visualiser les fichiers. Internet Explorer ouvre une fenêtre affichant tous ses fichiers temporaires, y compris les cookies. Recherchez les fichiers dont le nom commence par « Cookie: » dans la fenêtre ou recherchez les fichiers texte. Double-cliquez sur un cookie pour l'ouvrir dans votre éditeur de texte par défaut.

Vous pouvez également examiner vos cookies en localisant leurs fichiers texte sur votre disque dur. Internet Explorer stocke les cookies d'un site dans un fichier dont le nom est au format <utilisateur>@<domaine>.txt, où <utilisateur> est votre nom de compte. Par exemple, si votre nom est mikepope et que vous visitez le site www.contoso.com, les cookies de ce site se trouveront dans un fichier appelé mikepope@www.contoso.txt. (Ce nom peut inclure un numéro séquentiel : mikepope@www.contoso[1].txt.)

Les fichiers texte du cookie sont spécifiques à l'utilisateur, ils sont donc classés par compte. Dans Windows XP, par exemple, vous trouverez les fichiers des cookies dans un répertoire dont le chemin d'accès et le nom peuvent être :

c:\Mes documents et paramètres\<utilisateur>\Cookies

Pour trouver le cookie que vous avez créé, il est peut-être plus pratique de trier le répertoire par date de modification et de rechercher le fichier le plus récent.

Vous pouvez ouvrir le cookie avec un éditeur de texte. Si le fichier contient plusieurs cookies, ils sont séparés par un astérisque (*). La première ligne de chaque cookie correspond à son nom et la seconde contient les valeurs. Les autres lignes contiennent des informations relatives à la gestion interne du cookie comme la date et l'heure d'expiration. Le cookie contient également un checksum simple, si vous modifiez la longueur du nom ou la valeur du cookie, le navigateur détectera la fraude et le supprimera.

Cookies à valeurs multiples (sous-clés)

L'exemple précédent utilise un cookie pour chaque valeur que vous souhaitez stocker (Nom d'utilisateur, dernière visite). Vous pouvez également stocker plusieurs paires nom/valeur dans un seul cookie. Les paires nom/valeur sont considérées comme des « clés » ou des « sous-clés » selon ce que vous lisez. (Les sous-clés ressemblent énormément à la chaîne de requête dans une URL, si cela vous dit quelque chose). Par exemple, au lieu de créer deux cookies séparés nommés « userName » et « lastVisit », vous pouvez créer un cookie unique nommé « userInfo » et contenant les sous-clés «  userName » et « lastVisit ».

Il existe diverses justifications d'utilisation des sous-clés au lieu de cookies distincts. Il est évidemment logique de rassembler les informations liées ou similaires dans un seul cookie. De plus, étant donné que toutes les informations se trouvent dans un cookie unique, les attributs du cookie, comme l'expiration, s'appliquent à toutes les informations. (À l'inverse, naturellement, si vous souhaitez attribuer des dates d'expiration différentes à différents types d'informations, vous devez les stocker dans des cookies différents.)

Les sous-clés permettent également de réduire la taille des cookies. Ainsi qu'il a été mentionné précédemment dans la section Restrictions inhérentes aux cookies, les cookies sont limités à 4 096 octets et vous ne pouvez pas stocker plus de 20 cookies par site. En utilisant un cookie unique avec des sous-clés, vous utiliserez moins des 20 cookies autorisés pour votre site. En outre, un cookie unique occupe environ 50 caractères pour le traitement supplémentaire (informations d'expiration, etc.), à cela s'ajoute la longueur de la valeur que vous y avez stocké, tout ceci contribuant à approcher la limite de 4 Ko. Si vous stockez cinq sous-clés au lieu de cinq cookies distincts, vous éviterez le traitement supplémentaire de cookies séparés et vous pourrez économiser environ 200 octets.

En créant un cookie unique contenant des sous-clés, vous pouvez utiliser une variation de la syntaxe pour l'écriture d'un cookie unique. L'exemple suivant montre deux façons d'écrire le même cookie comportant deux sous-clés à chaque fois :

Response.Cookies("userInfo")("userName") = "mike"
Response.Cookies("userInfo")("lastVisit") = DateTime.Now.ToString
Response.Cookies("userInfo").Expires = DateTime.Now.AddDays(1)

Dim aCookie As New HttpCookie("userInfo")
aCookie.Values("userName") = "mike"
aCookie.Values("lastVisit") = DateTime.Now.ToString
aCookie.Expires = DateTime.Now.AddDays(1)
Response.Cookies.Add(aCookie)

Contrôle de la portée des cookies

Par défaut, tous les cookies d'un site sont stockés ensemble sur le client et ils sont envoyés au serveur avec toute demande vers ce site, en d'autres termes, chaque page d'un site reçoit tous les cookies de ce site. Il arrive parfois que vous ayez besoin de cookies avec un comportement plus spécifique. Vous pouvez définir la portée des cookies de deux façons :

  • En limitant la portée des cookies à un dossier du serveur ce qui, en pratique, vous permet de limiter les cookies à une application du site ;
  • En définissant la portée à un domaine ce qui vous permet de spécifier les sous-domaines d'un domaine pouvant accéder à un cookie.

Limitation des cookies à un dossier ou une application

Pour limiter des cookies à un dossier du serveur, définissez la propriété Path du cookie de la façon suivante :

Dim appCookie As New HttpCookie("AppCookie")
appCookie.Value = "written " & Now.ToString
appCookie.Expires = Now.AddDays(1)
appCookie.Path = "/Application1"
Response.Cookies.Add(appCookie)

Vous pouvez naturellement également écrire des cookies en définissant directement Response.Cookies, ainsi que je l'ai expliqué précédemment.

Le chemin peut être un chemin physique sous la racine du site ou une racine virtuelle. La conséquence est que le cookie sera disponible uniquement pour les pages du dossier ou de la racine virtuelle Application1. Par exemple, si votre site se nomme www.contoso.com, le cookie créé dans l'exemple précédent sera disponible pour les pages avec le chemin http://www.contoso.com/Application1/ et pour toutes les pages situées en dessous de ce dossier. Toutefois, le cookie ne sera pas disponible pour les pages d'autres applications comme http://www.contoso.com/Application2/ ou même http://www.contoso.com/.

Conseil Des tests effectués avec Internet Explorer et le navigateur Mozilla browser suggèrent que le chemin est sensible à la casse. Ce n'est d'ordinaire pas le cas des URL sur les serveurs Windows, mais il semblerait qu'il s'agisse d'une exception. Vous ne pouvez pas contrôler la façon dont les utilisateurs saisissent des URL dans leurs navigateurs, mais si votre application dépend de cookies liés à un chemin spécifique, veillez à ce que les URL contenues dans les liens hypertextes que vous créez correspondent à la casse de la valeur de la propriété Path.

Définition de la portée des cookies sur un domaine

Par défaut, les cookies sont associés à un domaine spécifique. Par exemple, si votre site est www.contoso.com, les cookies que vous écrivez sont envoyés vers le serveur lorsque les utilisateurs demandent n'importe quelle page de ce site (exception faite des cookies avec une valeur de chemin spécifique, ainsi que je viens de l'expliquer dans la section précédente). Si votre site contient des sous-domaines, par exemple, contoso.com, sales.contoso.com et support.contoso.com, vous pouvez alors associer les cookies comportant un sous-domaine spécifique. Pour ce faire, définissez la propriété Domaine du cookie, de la façon suivante :

Response.Cookies("domain").Value = DateTime.Now.ToString
Response.Cookies("domain").Expires = DateTime.Now.AddDays(1)
Response.Cookies("domain").Domain = "support.contoso.com"

Une fois le domaine défini de cette façon, le cookie est disponible uniquement pour les pages du sous-domaine spécifié.

Vous pouvez également utiliser la propriété Domain pour créer un cookie qui peut être partagé par plusieurs sous-domaines. Par exemple, définissez le domaine de la façon suivante :

Response.Cookies("domain").Value = DateTime.Now.ToString
Response.Cookies("domain").Expires = DateTime.Now.AddDays(1)
Response.Cookies("domain").Domain = "contoso.com"

Le cookie sera alors disponible pour le domaine principal, ainsi que pour sales.contoso.com et support.contoso.com.

Lecture des cookies

Lorsqu'un navigateur effectue une demande vers le serveur, il envoie les cookies de ce serveur avec la demande. Dans vos applications ASP.NET, vous pouvez lire les cookies à l'aide de l'objet Request. La structure de l'objet Request est fondamentalement la même que celle de l'objet Response, de telle sorte que vous pouvez lire les cookies à partir de l'objet Request de la même façon que vous avez écrit les cookies dans l'objet Response. Les exemples suivants illustrent les deux façons d'obtenir la valeur d'un cookie nommé « username » et d'afficher sa valeur dans un contrôle Label :

If Not Request.Cookies("userName") Is Nothing Then
 Label1.Text = Server.HtmlEncode(Request.Cookies("userName").Value)
End If

If Not Request.Cookies("userName") Is Nothing Then
 Dim aCookie As HttpCookie = Request.Cookies("userName")
 Label1.Text = Server.HtmlEncode(aCookie.Value)
End If

Avant d'essayer d'obtenir la valeur d'un cookie, assurez-vous que celui-ci existe bien. Sinon, vous obtiendrez une exception System.NullReferenceException Lien non MSDN France Site en anglais. Notez également que j'ai appelé la méthode HttpServerUtility.HtmlEncode Lien non MSDN France Site en anglais pour coder le contenu du cookie avant de l'afficher dans la page. Je le fais ici car j'affiche le contenu du cookie (ce que vous ne faites probablement pas d'ordinaire) et je veux être certain qu'aucun utilisateur malveillant n'a glissé de script exécutable dans le cookie. Pour obtenir davantage d'informations concernant la sécurité des cookies, reportez-vous à la section Cookies et sécurité.

Remarque Étant donné que chaque navigateur stocke les cookies différemment, divers navigateurs d'un même ordinateur ne seront pas nécessairement en mesure de lire leurs cookies respectifs. Par exemple, si vous utilisez Internet Explorer pour tester une page une fois, puis que vous utilisez un autre navigateur pour la tester à nouveau, le second navigateur ne trouvera pas les cookies enregistrés par Internet Explorer. Bien sûr, la plupart des gens utilisent généralement le même navigateur pour toutes leurs interactions Web, et ce n'est donc pas un problème dans la plupart des cas. Toutefois, vous pourriez vous y trouver confronté si vous testez votre application pour savoir si elle est compatible avec des navigateurs, par exemple.

Lire la valeur d'une sous-clé dans un cookie revient en fait à la définir. Voici une méthode permettant d'obtenir la valeur d'une sous-clé :

If Not Request.Cookies("userInfo") Is Nothing Then
 Label1.Text = _
 Server.HtmlEncode(Request.Cookies("userInfo")("userName"))
 Label2.text = _
 Server.HtmlEncode(Request.Cookies("userInfo")("lastVisit"))
End If

Dans l'exemple précédent, j'obtiens la valeur de la sous-clé « lastVisit » que j'ai définie précédemment comme la représentation sous forme de chaîne d'une valeur DateTime. N'oubliez pas que les cookies stockent des valeurs en tant que chaînes, ainsi si vous souhaitez utiliser la valeur lastVisit comme date, vous devez la convertir :

Dim dt As DateTime
dt = CDate(Request.Cookies("userInfo")("lastVisit"))

Les sous-clés d'un cookie sont saisies sous forme de collection du type NameValueCollection Lien non MSDN France Site en anglais. Par conséquent, vous pouvez également obtenir une sous-clé individuelle en récupérant la collection de sous-clés, puis en extrayant la valeur des sous-clés par nom, ainsi qu'il est indiqué ci-dessous :

If Not Request.Cookies("userInfo") Is Nothing Then
 Dim UserInfoCookieCollection As _
 System.Collections.Specialized.NameValueCollection
 UserInfoCookieCollection = Request.Cookies("userInfo").Values
 Label1.Text = Server.HtmlEncode(UserInfoCookieCollection("userName"))
 Label2.Text = Server.HtmlEncode(UserInfoCookieCollection("lastVisit"))
End If

De même que pour la définition du cookie, vous êtes libre de choisir la méthode vous permettant de lire un cookie.

Qu'est-ce que l'expiration ?

Vous pouvez lire le nom et la valeur d'un cookie, mais cela ne vous en apprendra guère plus. Les propriétés Domain et Path sont faciles à obtenir, mais leur utilisation est limitée. Par exemple, vous pouvez lire la propriété Domain, mais bien entendu, si votre page ne se trouve pas dans le même domaine que le cookie, de toutes façons vous ne l'auriez pas reçu.

En revanche, vous ne pouvez pas lire la date et l'heure d'expiration du cookie. Il se trouve que lorsque le navigateur envoie au serveur des informations relatives au cookie, celui-ci n'inclut pas les données d'expiration. Vous pouvez lire la propriété Expires, mais elle renvoie toujours une valeur date/heure égale à zéro.

Un peu plus haut dans la section Écriture des cookies de cet article, j'ai indiqué que le navigateur est responsable de la gestion des cookies, la propriété Expires en est l'illustration. Le principal objectif de la propriété Expires est d'aider le navigateur à gérer son stock de cookies en interne. Du point de vue du serveur, le cookie existe ou n'existe pas, l'expiration n'est donc pas une information utile côté serveur. Par conséquent, le navigateur ne fournit aucune information sur l'expiration lorsqu'il envoie le cookie. Si vous avez besoin de la date d'expiration d'un cookie, vous devez la réinitialiser, ainsi que je l'expliquerai brièvement dans la section Modification et suppression de cookies.

En clair, vous pouvez lire la propriété Expires d'un cookie que vous avez définie dans l'objet Response, avant que le cookie ne soit envoyé au navigateur. Toutefois, vous ne pouvez pas récupérer l'expiration dans l'objet Request.

Lecture de collections de cookies

Les exemples précédents supposent que vous souhaitez lire un cookie dont vous connaissez le nom. Vous pouvez occasionnellement avoir besoin de lire tous les cookies d'une page. Pour lire les noms et valeurs de tous les cookies d'une page, vous pouvez parcourir la collection Request.Cookies à l'aide du code suivant :

Dim i As Integer
Dim output As String = ""
Dim aCookie As HttpCookie
For i = 0 to Request.Cookies.Count - 1
 aCookie = Request.Cookies(i)
 output &= "Nom du cookie = " & Server.HtmlEncode(aCookie.Name) & "<br>"
 output &= "Valeur du cookie = " & Server.HtmlEncode(aCookie.Value) & _
 & "<br><br>"
Next
Label1.Text = output

Remarque Lorsque vous exécuterez ce code, vous verrez probablement un cookie nommé « ASP.NET_SessionId ». Il s'agit d'un cookie utilisé par ASP.NET pour stocker l'identificateur unique de votre session. Le cookie de la session n'est pas conservé sur votre disque dur. Pour obtenir davantage d'informations concernant les cookies de session, reportez-vous à la section Cookies et état de session de cet article.

L'exemple précédent ne s'applique pas si le cookie contient des sous-clés, car ces dernières sont alors affichées sous forme de chaîne unique nom/valeur. La propriété HasKeys Lien non MSDN France Site en anglais vous indique si le cookie contient des sous-clés. Si c'est le cas, vous pouvez descendre d'un niveau dans la collection de sous-clés pour obtenir les noms et valeurs de chaque sous-clé.

Comme je vous l'ai indiqué précédemment, il est possible d'obtenir des informations à propos des sous-clés à partir de la propriété Values Lien non MSDN France Site en anglais du cookie, qui est une collection du type NameValueCollection. Vous pouvez lire les valeurs des sous-clés à partir de la collection Values directement via la valeur d'index. Les noms de sous-clés correspondants sont disponibles dans le membre AllKeys Lien non MSDN France Site en anglais de la collection Values qui renvoie une collection de chaînes.

L'exemple suivant illustre une modification de l'exemple précédent. Il utilise la propriété HasKeys pour tester des sous-clés et, si ses sous-clés sont détectées, ces dernières sont récupérées à partir de la collection Values :

Dim i As Integer
Dim j As Integer
Dim output As String = ""
Dim aCookie As HttpCookie
Dim subkeyName As String
Dim subkeyValue As String
For i = 0 To Request.Cookies.Count - 1
 aCookie = Request.Cookies(i)
 output &= "Nom = " & aCookie.Name & "<br>"
 If aCookie.HasKeys Then
For j = 0 To aCookie.Values.Count - 1
subkeyName = Server.HtmlEncode(aCookie.Values.AllKeys(j))
subkeyValue = Server.HtmlEncode(aCookie.Values(j))
output &= "Nom de la sous-clé = " & subkeyName & "<br>"
output &= "Valeur de la sous-clé = " & subkeyValue & "<br><br>"
Next
Else
 output &= "Valeur = " & Server.HtmlEncode(aCookie.Value) & "<br><br>"
 End If
Next
Label1.Text = output

Vous pouvez également extraire les sous-clés sous forme d'objet NameValueCollection, ainsi qu'illustré ci-dessous :

If aCookie.HasKeys Then
 Dim CookieValues As _
System.Collections.Specialized.NameValueCollection = aCookie.Values
Dim CookieValueNames() As String = CookieValues.AllKeys
For j = 0 To CookieValues.Count – 1
subkeyName = Server.HtmlEncode(CookieValueNames(j))
subkeyValue = Server.HtmlEncode(CookieValues(j))
 output &= "Nom de la sous-clé = " & subkeyName & "<br>"
 output &= "Valeur de la sous-clé = " & subkeyValue & "<br><br>"
 Next
Else
 output &= "Valeur = " & aCookie.Value & "<br><br>"
End If

Remarque N'oubliez pas que j'appelle la méthode Server.HtmlEncode uniquement parce que j'affiche les valeurs des cookies de la page. Si vous ne faites que tester la valeur d'un cookie, vous n'avez pas besoin de coder la valeur avant de l'utiliser.

Modification et suppression de cookies

Il est possible que vous ayez parfois besoin de modifier un cookie, afin de changer sa valeur ou d'étendre sa durée d'expiration, par exemple. (N'oubliez pas que vous ne pouvez pas lire la date d'expiration d'un cookie car le navigateur ne transmet pas les informations d'expiration au serveur.)

En réalité, vous ne modifiez pas directement le cookie. Bien que vous puissiez obtenir un cookie à partir de la collection Request.Cookies et le manipuler, le cookie, lui-même, se trouve quelque part sur le disque dur de l'utilisateur. Ainsi, modifier un cookie consiste en fait à créer un nouveau cookie avec de nouvelles valeurs, puis à l'envoyer au navigateur pour en écraser l'ancienne version sur le client.

L'exemple suivant montre comment il est possible de changer la valeur d'un cookie stockant le compte des visites d'un utilisateur sur le site :

Dim counter As Integer
If Request.Cookies("counter") Is Nothing Then
 counter = 0
Else
 counter = CInt(Request.Cookies("counter").Value)
End If
counter += 1
Response.Cookies("counter").Value = counter.ToString
Response.Cookies("counter").Expires = DateTime.Now.AddDays(1)

Ou encore :

Dim ctrCookie As HttpCookie
Dim counter As Integer
If Request.Cookies("counter") Is Nothing Then
 ctrCookie = New HttpCookie("counter")
Else
 ctrCookie = Request.Cookies("counter")
End If
counter = CInt(ctrCookie.Value) + 1
ctrCookie.Value = counter.ToString
ctrCookie.Expires = DateTime.Now.AddDays(1)
Response.Cookies.Add(ctrCookie)

Suppression de cookies

La suppression d'un cookie (c'est-à-dire le fait de l'éliminer physiquement du disque dur de l'utilisateur) revient à le modifier. Vous ne pouvez pas directement supprimer un cookie puisque ce dernier se trouve sur l'ordinateur de l'utilisateur. Toutefois, vous pouvez faire en sorte que le navigateur le supprime pour vous. La technique consiste à modifier le cookie ainsi qu'il est décrit ci-dessus (c'est-à-dire à créer un nouveau cookie portant le même nom), mais en définissant son expiration à une date antérieure. Lorsque le navigateur vérifie l'expiration du cookie, il le supprime car il a expiré.

Supprimer un cookie revient donc à le créer, à l'exception que vous définissez une date d'expiration antérieure à la date en cours. L'exemple ci-dessus va au-delà de la simple suppression d'un cookie, il montre comment supprimer tous les cookies du présent domaine :

Dim i As Integer
Dim cookieName As String
Dim limit As Integer = Request.Cookies.Count - 1
For i = 0 To limit
 aCookie = Request.Cookies(i)
 aCookie.Expires = DateTime.Now.AddDays(-1)
 Response.Cookies.Add(aCookie)
Next

Modification ou suppression de sous-clés

Modifier des sous-clés individuelles revient d'abord à les créer :

Response.Cookies("userInfo")("lastVisit") = DateTime.Now.ToString
Response.Cookies("userInfo").Expires = DateTime.Now.AddDays(1)

Supprimer une sous-clé individuelle se révèle être un problème plus complexe. Il ne s'agit pas simplement de réinitialiser la date d'expiration du cookie, car cela supprimerait la totalité du cookie au lieu de supprimer seulement une sous-clé. La solution est plutôt de manipuler la collection Values du cookie, contenant les sous-clés. Commencez par récréer le cookie en le récupérant de l'objet Request.Cookies. Vous pouvez alors appeler la méthode Remove de la collection Values, en transmettant à la méthode Remove le nom de la sous-clé à supprimer. Puis, comme d'habitude, vous ajoutez le cookie modifié à la collection Response.Cookies de façon à ce qu'il soit envoyé au navigateur sous sa forme modifiée.

Le code suivant montre comment supprimer une sous-clé. Dans cet exemple, le nom de la sous-clé à supprimer est spécifié dans une variable.

Dim subkeyName As String
subkeyName = "userName"
Dim aCookie As HttpCookie = Request.Cookies("userInfo")
aCookie.Values.Remove(subkeyName)
aCookie.Expires = DateTime.Now.AddDays(1)
Response.Cookies.Add(aCookie)

Cookies et sécurité

Lorsque vous utilisez des cookies, vous devez connaître leurs vulnérabilités inhérentes. Par vulnérabilité, je ne parle des problèmes de confidentialité, ainsi qu'il sont décrits dans l'article cité précédemment dans la section Qu'est-ce qu'un cookie ?. En effet, la confidentialité constitue surtout un problème pour les utilisateurs qui sont préoccupés par la façon dont certaines informations peuvent être utilisées. Les problèmes de sécurité inhérents aux cookies sont similaires à ceux rencontrés lors de la récupération de données auprès du client. Pour vous, qui êtes débutant, et pour ce qui est de votre application, les cookies ne sont rien d'autre qu'une entrée utilisateur et sont donc sujets aux intrusions et aux usurpations. Un utilisateur peut au minimum voir les données que vous stockez dans un cookie, étant donné que celui-ci est stocké sur son propre ordinateur, mais il peut également le modifier avant que le navigateur ne vous le renvoie.

Par conséquent, vous ne devez jamais stocker d'informations sensibles dans un cookie, telles que des noms d'utilisateur, des mots de passe, des numéros de carte de crédit, etc. Ne mettez rien dans un cookie qui ne doive se trouver dans les mains d'un utilisateur ou de quelqu'un qui pourrait se l'approprier de quelque manière que ce soit.

De même, restez méfiant à l'égard des informations que vous récupérez dans un cookie. Ne supposez pas que ses données n'ont pas été modifiées depuis leur écriture ; lorsque vous traitez des valeurs de cookies, utilisez les mêmes mesures de sécurité que lorsque vous utilisez les données saisies par un utilisateur dans une page Web. J'applique par exemple un code HTML au contenu d'un cookie avant d'afficher sa valeur dans une page. Vous le faites habituellement pour désinfecter les informations que vous affichez après les avoir récupérées auprès d'un utilisateur. Le fait de travailler avec des cookies n'est guère différent.

Un autre problème est que les cookies sont échangés entre le navigateur et le serveur sous forme de texte en clair, ainsi toute personne parvenant à intercepter votre trafic Web peut lire le cookie. Vous pouvez définir une propriété n'autorisant la transmission du cookie uniquement si la connexion utilise le protocole Secure Sockets Layer (SSL, ie https://). SSL n'empêche pas de lire ou de manipuler le cookie alors qu'il se trouve sur l'ordinateur de l'utilisateur, mais il empêche son interception en cours de transit. Je ne vais pas traiter du protocole SSL dans cet article, mais sachez que vous pouvez ajouter des protections de transmission aux cookies. Pour obtenir davantage d'informations à propos de SSL, reportez-vous à l'article Secure Sockets Layer: Protect Your E-Commerce Web Site with SSL and Digital Certificates Lien non MSDN France Site en anglais.

Au regard de ces problèmes de sécurité, comment utiliser des cookies en toute sécurité ? Vous pouvez stocker des données non critiques dans des cookies comme les préférences d'un utilisateur ou d'autres informations, qui si elles sont compromises, n'auront aucun effet notoire sur votre application. Si vous souhaitez stocker des informations sensibles comme un ID d'utilisateur dans un cookie, vous pouvez le coder. Pour ce faire, vous pouvez utiliser l'utilitaire ASP.NET Forms Authentication pour créer un ticket d'authentification à stocker dans un cookie. Je n'ai pas abordé les questions de codage dans cet article, mais si vous souhaitez stocker des données sensibles dans un cookie, vous devez étudier les différentes possibilités de soustraire ces informations des regards indiscrets et des usurpateurs potentiels.

Vous trouverez de plus amples informations sur les cookies et les vulnérabilités qui en résultent en matière de sécurité dans l'article Mitigating Cross-site Scripting With HTTP-only Cookies Lien non MSDN France Site en anglais.

Comment vérifier si un navigateur accepte les cookies

Dans la section Restrictions inhérentes aux cookies, j'ai évoqué le fait qu'un utilisateur peut configurer son navigateur afin de refuser les cookies. Comment savoir si vous pouvez écrire et lire des cookies ? Aucune erreur n'est déclenchée en cas de refus d'écriture d'un cookie (par exemple, Response.Cookies ne renvoie pas d'exception), car le serveur ne garde aucune trace des événements une fois la page restituée. De même, le navigateur ne transmet aucune information au serveur à propos des paramètres actifs du cookie. (Si vous vous posez la question, la propriété HttpBrowserCapabilities.Cookies Property Lien non MSDN France Site en anglais ne vous indique pas si les cookies sont activés, elle indique uniquement si le navigateur utilisé supporte les cookies.)

Vous pouvez déterminer si les cookies sont acceptés en essayant d'écrire un cookie, puis de le lire. Si vous ne parvenez pas à lire le cookie que vous avez écrit, vous pouvez supposer que les cookies sont refusés par le navigateur.

J'ai imaginé un exemple simple pour vous aider à savoir si les cookies sont acceptés. L'exemple comporte deux pages. Sur la première page, j'ai écrit un cookie, puis j'ai redirigé le navigateur vers la seconde page. La seconde page essaie de lire le cookie. Elle redirige à son tour le navigateur vers la première page, ajoutant à l'URL une variable de la chaîne de requête contenant les résultats du test.

Le code de la première page se présente comme suit :

Sub Page_Load()
 If Not Page.IsPostBack Then
 If Request.QueryString("AcceptsCookies") Is Nothing Then
 Response.Cookies("TestCookie").Value = "ok"
 Response.Cookies("TestCookie").Expires = _
 DateTime.Now.AddMinutes(1)
 Response.Redirect("TestForCookies.aspx?redirect=" & _
 Server.UrlEncode(Request.Url.ToString))
 Else
 labelAcceptsCookies.Text = "Accepte les cookies = " & _
 Request.QueryString("AcceptsCookies")
 End If
 End If
End Sub

La première page effectue un test pour savoir s'il s'agit d'un postback, et si ce n'est pas le cas, elle recherche la variable de la chaîne de requête (AcceptsCookies) contenant les résultats du test. S'il n'existe aucune variable de la chaîne de requête, cela signifie que le test n'est pas terminé, le code écrit donc un cookie appelé « TestCookie ». Après l'écriture du cookie, l'exemple appelle Response.Redirect pour transférer la page de test (TestForCookies.aspx). Une variable de la chaîne de requête appelée redirect et contenant l'URL de la page active est ajoutée à l'URL de cette page de test ; elle permettra une redirection vers cette page après l'exécution du test.

La page de test peut être entièrement composée de code, les contrôles sont inutiles. Voici le code que j'ai utilisé :

Sub Page_Load()
 Dim redirect As String = Request.QueryString("redirect")
 Dim acceptsCookies As String
 ' Le cookie a-t-il été accepté ?
 If Request.Cookies("TestCookie") Is Nothing Then
 ' Aucun cookie, il ne doit donc pas avoir été accepté
 acceptsCookies = 0
 Else
 acceptsCookies = 1
 ' Supprimez le cookie test
 Response.Cookies("TestCookie").Expires = _
 DateTime.Now.AddDays(-1)
 End If
 Response.Redirect(redirect & "?AcceptsCookies=" & acceptsCookies, _
 True)
End Sub

Après lecture de la variable de la chaîne de requête redirect, le code essaie de lire le cookie. À des fins de gestion interne, si le cookie n'existe pas vraiment, il est immédiatement supprimé. Lorsque le test est terminé, le code construit une nouvelle URL à partir de celle transmise dans la variable de la chaîne de requête redirect. Cette nouvelle URL inclut également une variable de la chaîne de requête contenant les résultats du test. L'étape finale consiste à utiliser cette nouvelle URL pour rediriger le navigateur vers la page d'origine.

Cet exemple est particulièrement simple, mais il illustre parfaitement le principe de base du test qui consiste à lancer la procédure et à examiner ce qui se passe. Une amélioration évidente serait de conserver les résultats des tests des cookies dans un magasin persistant de façon à ne pas répéter le test à chaque fois que l'utilisateur affiche la page d'origine. Toutefois, ceci est un peu plus complexe qu'il n'y paraît. Les cookies ne fonctionneront pas pour d'évidentes raisons. Une autre possibilité serait de stocker les résultats de test dans l'état de session, mais, par défaut, celui-ci utilise également des cookies et si le navigateur n'accepte pas les cookies, l'état de session ne fonctionnera pas non plus. La solution à ce dernier problème consiste à utiliser un état de session « sans cookie ». Dans la section suivante, je décris brièvement comment l'état de session utilise les cookies.

Cookies et état de session

Lorsqu'un utilisateur navigue sur votre site, le serveur établit une session unique pour ce dernier qui dure toute la durée de sa visite. Pour chaque session, ASP.NET gère une structure basée sur un serveur (« état de session ») où les applications peuvent stocker des informations spécifiques à l'utilisateur. Pour obtenir davantage d'informations, reportez-vous à l'article Session State Lien non MSDN France Site en anglais

ASP.NET doit pouvoir être en mesure de déterminer un ID de session pour chaque utilisateur de façon à faire correspondre l'utilisateur et les informations relatives à l'état de session sur le serveur. Par défaut, ASP.NET utilise un cookie non persistant pour stocker l'état de session. Si vous utilisez l'exemple de code du paragraphe « Lecture de collections de cookies » de la section Lecture des cookies, vous identifierez probablement un cookie d'état de session parmi les cookies.

Toutefois si un utilisateur a désactivé les cookies sur son navigateur, l'état de session ne peut pas utiliser un cookie pour stocker l'ID de session et l'état de session ne fonctionne donc pas. C'est pourquoi j'ai affirmé précédemment dans la section Comment vérifier si un navigateur accepte les cookies qu'après avoir testé les cookies, il ne serait peut-être pas une bonne idée de stocker les résultats du test dans l'état de session : pas de cookie, pas d'état de session.

ASP.NET propose une solution de rechange sous la forme de sessions « sans cookie ». Vous pouvez configurer votre application de façon à ce que les ID de session ne soient pas stockés dans un cookie, mais dans les URL des pages de votre site. En conservant l'ID de session dans l'URL, ASP.NET stocke l'ID dans le navigateur, d'une certaine façon, et peut le récupérer lorsque l'utilisateur demande une autre page.

Les sessions sans cookie permettent de contourner le problème rencontré lorsqu'un navigateur refuse les cookies et vous permet de travailler avec l'état de session. Si votre application utilise l'état de session, il vous faudra peut-être la configurer de façon à ce qu'elle utilise des sessions sans cookie. Toutefois, dans certains cas bien définis, si l'utilisateur partage l'URL avec quelqu'un d'autre, par exemple, pour l'envoyer par courrier électronique à un collègue tandis que sa session est encore active, il est possible que les utilisateurs en viennent à partager la même session ce qui peut provoquer des résultats imprévisibles.

Pour obtenir davantage d'informations sur la configuration de votre application afin qu'elle puisse utiliser des sessions sans cookie, reportez-vous à l'article Vue d'ensemble de la gestion d'état ASP.NET Lien non MSDN France de la base de connaissances.



Dernière mise à jour le jeudi 3 avril 2003



Pour en savoir plus
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft. Tous droits réservés.