De nombreux développeurs ne considèrent jamais le concept d'État avant de livrer des applications sur le Web. Comme mentionné précédemment, le Web est un environnement apatride. Par conséquent, nous devons discuter de l'État et comprendre les méthodes qui peuvent éviter les problèmes.
Définition précise du statut
Dans un programme à user unique, lors de la création d'une application exécutable, comme l'utilisation de VB pour créer un fichier .exe, vous pouvez déclarer une variable globale (ou publique), puis y accéder n'importe où dans le code. La valeur du moment est toujours valide et accessible à tout moment, l'application est en cours d'exécution.
Pour une solution client / serveur traditionnel, comme un système dans lequel une application basée sur le client accède à un moteur de base de données basé sur le serveur, chaque client établit une connexion au serveur et à l'application de base de données. Cette connexion est généralement établie en vérifiant l'utilisateur.
Le processus de vérification est un processus typique d'identification d'un utilisateur, ce qui prouve s'il s'agit d'un utilisateur légitime via une combinaison de nom d'utilisateur et de mot de passe.
Une fois authentifié, une connexion est établie entre le client et l'application basée sur le serveur, qui reste valable pour tout le temps que l'utilisateur a utilisé l'application. Cela se produit lorsque l'utilisateur s'inscrit sur le serveur Windows 2000 fermenté. Chaque fois qu'un administrateur utilise l'utilitaire des utilisateurs et des ordinateurs Active Directory (cliquez sur l'élément de gestion de la répertoire dans l'option d'outils d'administration dans le menu Démarrer) pour observer les connexions utilisateur actives. Ce processus est le même dans de nombreux systèmes, comme Microsoft SQL Server.
Cette connexion permanente signifie que lorsqu'un utilisateur envoie des instructions ou des demandes au serveur, le serveur identifie facilement chaque utilisateur. La même réponse du serveur ou toute autre information utilisateur peut également être renvoyée directement à l'utilisateur. Il est en outre noté que le serveur peut stocker plus facilement les valeurs et les informations liées à chaque client et les fournir au client correspondant en cas de besoin. Bien sûr, les applications de serveur peuvent avoir les principales variables globales auxquelles les utilisateurs peuvent accéder en cas de besoin.
Cette capacité à identifier les demandes de chaque client et à enregistrer les valeurs de l'utilisateur concerné en mémoire constitue l'état. L'état peut être considéré comme représentant la valeur, l'environnement et les variables internes de l'application de l'utilisateur et exécute l'ensemble du processus de l'application et de la connexion utilisateur.
L'importance du statut
Si vous avez l'intention de créer une application basée sur le site Web qui interagit avec l'utilisateur, plutôt qu'un site Web qui affiche uniquement des pages indépendantes, vous devez être en mesure de fournir un statut distinct pour chaque utilisateur. Cela peut simplement se souvenir de leur nom, ou il peut également s'agir de stocker des références d'objets ou différents ensembles de dossiers pour chaque utilisateur. Si vous ne pouvez pas le faire, la page Web ASP ne peut pas faire plus, car lorsque la page est exécutée, les variables et autres informations connexes dans la page sont détruites. Lorsque l'utilisateur demande la page suivante, toutes les informations fournies par cette page seront perdues.
Par conséquent, il est nécessaire de trouver un moyen de sauvegarder l'état de chaque visiteur. Il est très important de pouvoir stocker des valeurs globales pour tous les utilisateurs. Par exemple, un accès de style Web ou une page cliquez sur un compteur qui ne fournit pas à chaque utilisateur son propre compteur, et les utilisateurs veulent généralement voir le nombre total de visiteurs, pas seulement le nombre de visites qu'ils visitent elles-mêmes. Le nombre de visiteurs doit être stocké avec l'état au niveau de l'application, pas avec l'état au niveau de l'utilisateur.
Ce n'est pas un problème qui vient d'émerger. Il existe donc de nombreuses solutions traditionnelles pour stocker l'état sur le Web. Les administrateurs de sites Web souhaitent savoir si les visiteurs ont déjà visité leur site Web, et si oui, combien de fois ont-ils visité? Visitez également régulièrement d'autres sites Web. Cela rendra meilleur pour définir ses objectifs publicitaires. Tout cela nécessite un moyen de stocker des informations sur les demandes de page Web générées par l'utilisateur pendant l'accès ou entre chaque visite.
Créer un statut sur le Web
Un moyen courant de fournir un statut entre les demandes de page et l'accès au site est par le biais des cookies. Nous avons vu dans les chapitres précédents comment stocker les valeurs correspondantes dans l'ordinateur du client, qui sont envoyées avec chaque demande de page au domaine valide pour ce cookie. En vérifiant et en mettant à jour les cookies avec ASP, il est possible de maintenir un état dans une certaine mesure. Les informations incluses peuvent être utilisées pour identifier l'utilisateur, puis connecter l'utilisateur à un ensemble de valeurs correspondantes stockées.
Par exemple, il peut être détecté si une demande utilisateur contient un cookie spécifié de site. S'il n'est pas inclus, l'utilisateur se voit attribuer un certain type d'identité, spécifiant un nombre et stocké dans un cookie avec une longue période de validité. Chaque fois que l'utilisateur visite ce site à l'avenir, il sera en mesure de détecter les cookies et de mettre à jour les informations contenues. Des données sur le nombre et la durée des visites peuvent également être collectées et stockées sur le serveur pour une utilisation future.
Mais que se passe-t-il si un utilisateur transfère à un autre ordinateur, ou supprime un cookie, ou si son navigateur refuse de recevoir le cookie qui leur est envoyé? Dans ce cas, l'État ne peut pas être maintenu car ils ne seront pas reconnus la prochaine fois. Si vous ouvrez l'option Warn avant d'accepter les cookies dans votre navigateur, puis parcourez quelques grands sites, vous comprendrez le sens.
1 et 1 Visiteurs anonymes et visiteurs autorisés
Si vous pensez que les cookies sont une solution un peu bâclée, vous pouvez utiliser une approche plus simple. Une approche que de nombreux sites utilisent consiste à faire apparaître une boîte de dialogue de connexion lorsqu'un visiteur clique sur un site ou lorsqu'une page qui nécessite une vérification de l'identité. Les visiteurs doivent d'abord s'inscrire et obtenir un certain type de combinaison de nom d'utilisateur / mot de passe afin de permettre l'accès au site ou à la page correspondant.
Pour prouver que le visiteur est un utilisateur connu et légitime, un cookie placé sur l'ordinateur du visiteur enregistre des données d'enregistrement détaillées ou une clé indiquant que l'identité a été vérifiée. Dans le même temps, les données détaillées du visiteur sont enregistrées en permanence sur le serveur et prêtes à être utilisées lors de l'accès à nouveau. Si le visiteur a un tel cookie dans son navigateur, il peut accéder librement sur le site Web car il a été vérifié.
Si le cookie n'a pas de période de validité (expire), la valeur du cookie disparaîtra automatiquement lorsque le navigateur est fermé et doit être réinscrit et vérifié à nouveau lors de la prochaine visite. Bien sûr, si vous refusez de recevoir des cookies ou de supprimer des cookies, vous ne pouvez obtenir que la boîte de dialogue d'inscription. De cette façon, s'il n'est pas reconnu, le site ne peut être accessible.
En obligeant les utilisateurs à s'inscrire auprès d'un serveur Web, tout comme l'inscription à leur propre réseau, les performances de sécurité globales de Windows 2000 offrent à IIS des capacités de vérification plus solides et plus sûres. Cependant, cela ne peut fonctionner qu'avec des navigateurs avec Internet Explorer 3.0 et plus. IIS peut également utiliser la vérification de base pour permettre aux navigateurs non microsoft d'enregistrer un serveur Web.
2 Plus de visiteurs anonymes
Lorsque vous utilisez ASP sur un serveur Web IIS, les utilisateurs peuvent être suivis dans la session actuelle à moins que l'utilisateur ne laisse le site sur un autre site Web ou ferme le navigateur. Plus tard dans ce chapitre, vous verrez comment cette fonctionnalité est utilisée pour identifier un visiteur, stocker les informations locales de l'utilisateur et fournir un statut. Ce qui suit est une discussion sur son fonctionnement par rapport aux solutions déjà discutées.
ASP et IIS ont proposé conjointement un concept de sessions utilisateur, interagissant via des objets de session ASP. Lorsque chaque visiteur accède d'abord à une page Web ASP sur le serveur, créez un nouvel objet de session indépendant pour lui, affectez un numéro d'identification de session à la session et ajoutez une version cryptée spéciale de l'identifiant de session.
Le chemin du cookie (voir le chapitre précédent pour la description des attributs de cookie) est défini sur le chemin racine de l'application ASP exécutée sur le serveur. Il s'agit probablement du répertoire racine du site Web par défaut (c'est-à-dire /), mais cela peut également être une autre valeur (voir plus tard). La valeur expirée n'est pas fournie dans le cookie, donc lorsque le navigateur est fermé, la valeur des cookies disparaît.
Chaque fois que cet utilisateur visite cette page Web ASP, l'ASP recherchera ce cookie. Nommé AspSessionIdxxxxxxxxx, où chaque X est un caractère alphabétique. Dans la collection ServerVariables illustrée à la figure 2-7 du chapitre 2, vous pouvez le voir dans l'en-tête HTTP.
Cependant, ce cookie n'apparaît pas dans la collection de demande.cookies ou de réponse. Pour chaque demande de page Web ASP, l'ASP doit afficher la valeur. La valeur contenue dans ce cookie indique la session de l'utilisateur. Par conséquent, le contenu de l'objet de session correspondant (qui a été traité en mémoire et contient toujours toutes les valeurs qui fonctionnaient au cours du processus de demande de page précédent) peuvent être remises au script dans la page Web ASP.
Bien sûr, comme mentionné précédemment, si le navigateur du client ne reçoit pas ou ne prend pas en charge ces cookies, ce traitement échouera. Dans ce cas, une session ASP ne peut pas être créée et l'état de ce visiteur n'est pas automatiquement maintenu.