> Développement - ASP SOURCE : http://www.microsoft.com/france/

[ RETOUR ]

Active Server Pages (ASP) facilite la génération de contenu dynamique et la conception de puissantes applications pour le Web. Que vous soyez créateur ou développeur pour le Web, cette introduction explique en quoi ASP peut vous aider.

ACTIVE SERVER PAGES

Microsoft® Active Server Pages (ASP) est un environnement de développement de scripts serveur, que vous pouvez utiliser pour créer des applications serveur pour le Web, à la fois dynamiques et interactives. Avec ASP, vous pouvez associer les pages HTML, les commandes de script et les composants ActiveX pour créer des pages Web interactives ou de puissantes applications basées sur le Web. Les applications ASP sont simples à développer et à modifier.

À l'intention de l'auteur utilisant HTML

Si vous êtes un auteur utilisant HTML, vous trouverez que les scripts ASP sont un moyen simple pour commencer à créer des pages interactives. Si vous souhaitez recueillir des informations à partir d'un formulaire HTML, personnaliser un document HTML avec le nom d'un utilisateur ou utiliser différentes fonctions HTML selon les navigateurs, ASP peut représenter une solution très séduisante. Jusqu'à maintenant, pour recueillir les informations d'un formulaire HTML, il fallait apprendre un langage de programmation afin de concevoir une application CGI (Common Gateway Interface). Désormais, vous pouvez recueillir et analyser les données d'un formulaire en utilisant des instructions simples que vous incorporez directement à vos documents HTML. Vous n'avez pas à apprendre un langage de programmation tout entier ni à compiler séparément des programmes pour créer des pages interactives.

Au fur et à mesure que vos connaissances d'ASP et des langages de script augmenteront, vous pourrez créer des scripts de plus en plus complexes. Avec ASP, vous utilisez très facilement les composants ActiveX pour effectuer des tâches complexes, comme la connexion à une base de données pour le stockage et la récupération d'informations.

À l'intention de l'auteur expérimenté en scripts

Si vous connaissez déjà un langage de script, comme VBScript, JavaScript ou PERL, vous savez déjà utiliser Active Server Pages. Dans vos pages ASP, vous pouvez utiliser n'importe quel langage de script pour lequel vous disposez d'un moteur de script respectant la norme de script ActiveX. ASP est fourni avec des moteurs de script pour Microsoft® Visual Basic® Scripting Edition (VBScript) et Microsoft® JScript™, afin que vous puissiez immédiatement vous mettre à écrire des scripts. Les moteurs de script ActiveX pour PERL, REXX et Python sont disponibles auprès de développeurs indépendants.

À l'intention du développeur Web

Si vous connaissez déjà un langage de programmation, comme Visual Basic, vous trouverez que ASP est un moyen simple et rapide de créer des applications pour le Web. En ajoutant des commandes de script à vos pages HTML, vous créerez une interface HTML pour votre application. En créant vos propres composants ActiveX, vous serez en mesure d'intégrer la logique commerciale de votre application à des modules réutilisables pouvant être appelés à partir d'un script, d'un autre composant ou d'un autre programme.

L'utilisation d'ASP pour le Web se traduit par des avantages concrets, permettant ainsi aux fournisseurs de contenu sur le Web, d'offrir des applications commerciales interactives au lieu d'une simple publication. Ainsi, une agence de voyage peut faire mieux que de publier des horaires de vols ; elle peut utiliser les scripts ASP pour permettre aux clients de connaître les vols disponibles, comparer les prix ou effectuer des réservations.

Microsoft Transaction Server (MTS), qui est inclus dans Microsoft Windows NT Option Pack, réduit le coût et la complexité d'élaboration des applications sur serveur. MTS gère la complexité du développement d'applications Web sécurisées, évolutives et fiables.

Modèle Active Server Pages

Un script ASP commence son exécution lorsqu'un navigateur demande un fichier .asp à votre serveur Web. Votre serveur Web appelle alors ASP, qui lit le fichier demandé du début à la fin, exécute toutes les commandes de script et envoie une page Web au navigateur.

Étant donné que vos scripts s'exécutent sur le serveur plutôt que sur la machine client, votre serveur Web effectue tout le travail lié à la génération des pages Web envoyées aux navigateurs. Il vous importe peu de savoir si un navigateur peut traiter ou non vos scripts : votre serveur Web effectue tout le travail de traitement du script et de transmission du HTML standard au navigateur. Les scripts serveur ne peuvent être copiés facilement car seul le résultat du script est envoyé au navigateur. Les utilisateurs ne peuvent voir les commandes de script ayant servi à créer la page qu'ils visualisent.

Une application de type ASP est une collection de pages ASP et de composants ActiveX. Lorsque vous définissez une application, vous utilisez le Gestionnaire des services Internet afin de désigner le répertoire de départ de l'application au sein de votre site Web. Tous les fichiers et dossiers se trouvant dans le répertoire de départ de votre site Web sont considérés comme faisant partie intégrante de l'application jusqu'à ce qu'un autre répertoire de départ soit trouvé. Vous utilisez donc les limites des répertoires pour définir l'étendue d'une application. Vous pouvez avoir plusieurs applications par site Web, et chacune d'elles peut être configurée différemment.

Gestion d'applications

Windows NT Option Pack fournit des services de gestion d'applications ASP sur un serveur Web. Par exemple, le Gestionnaire des services Internet donne au développeur d'applications un outil d'administration simple à utiliser, qui permet de définir les propriétés d'une application. En outre, Active Server Pages offre des fonctionnalités de script qui permettent à vos applications de stocker des données globales. Cette rubrique présente brièvement certaines de ces fonctionnalités de gestion d'applications et propose des liens permettant d'accéder à des informations plus détaillées.

Démarrage et arrêt d'une application

Une application démarre dès que le serveur Web reçoit une requête pour une page ASP de cette application. Elle se termine lorsque le serveur Web est arrêté ou que vous la stoppez à l'aide du bouton Décharger du Gestionnaire des services Internet. Vous ne pouvez utiliser le bouton Décharger que sur des applications s'exécutant dans une zone mémoire différente (isolée) du traitement effectué par le serveur Web.

Isolement d'une application

Les applications ASP s'exécutent normalement dans la même zone mémoire, ou de traitement, que le serveur Web. Bien que les performances d'une application ASP soient ainsi améliorées, le traitement effectué par le serveur Web est exposé à certains risques si l'application connaît une défaillance. Vous pouvez isoler une application en l'exécutant dans une zone mémoire séparée du serveur Web. Si l'application ASP est défaillante, cela n'aura aucune incidence sur les autres applications ni sur le serveur Web.

Utilisation de l'état de l'application

Lorsque vous écrivez une application, vous devrez peut-être mettre certaines informations sur l'application à la disposition de ses utilisateurs. Par exemple, vous pouvez souhaiter créer des variables permettant aux administrateurs système de personnaliser une application pour leur site en définissant un message d'accueil différent ou en modifiant la police de titre sur toutes les pages ASP. Ces modifications seront visibles par tous les visiteurs du site.

Il existe plusieurs manières de mettre des données à disposition de tous les utilisateurs d'une application à partir de toutes les pages de cette application. La méthode la plus fréquente consiste à donner une étendue Application à une variable ou à une instance d'objet en la stockant dans l'objet Application ASP. L'étendue Application est utile pour des données globales, telles qu'un compteur global, ou des informations globales de configuration d'applications, telles que les informations stockées dans le registre ou la métabase.

Il se peut également que vous deviez écrire des scripts qui s'exécutent à chaque démarrage ou arrêt d'une application.

Gestion de sessions

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 :

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 :

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 :

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. 

<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 :

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.

Protection d'une application ASP

Ne sous-estimez pas l'importance d'une configuration adéquate des paramètres de sécurité. Outre le fait que vos applications ASP soient exposées à des risques de piratage, une mauvaise configuration des paramètres de sécurité peut également empêcher les vrais utilisateurs d'accéder à vos fichiers .asp.

Votre serveur Web vous offre toute une palette de méthodes de protection de vos applications ASP contre les accès et les modifications non autorisés. Après avoir pris connaissance des informations relatives à la sécurité présentées dans cette rubrique, prenez le temps de lire attentivement votre documentation concernant la sécurité de Windows NT et du serveur Web.

Permissions NTFS

Vous pouvez garantir la sécurité vos fichiers d'application ASP en appliquant les permissions d'accès NTFS à chaque fichier et répertoire. Les permissions NTFS, qui représentent la base du système de sécurité de votre serveur Web, définissent les différents niveaux d'accès aux fichiers et répertoires que l'on affecte à un utilisateur ou groupe d'utilisateur. Lorsqu'un utilisateur disposant d'un compte Windows NT valide tente d'accéder à un fichier à accès réservé, votre ordinateur vérifie la liste de contrôle d'accès (ACL, Access Control List) du fichier, qui définit les permissions affectée aux différents comptes et groupes d'utilisateurs. Si le compte de l'utilisateur dispose de permissions suffisantes pour ouvrir le fichier, l'ordinateur accorde l'accès. Exemple : le propriétaire d'une application Web stockée sur votre serveur Web aura besoin des permissions de modification pour pouvoir visualiser, modifier et supprimer les fichiers .asp de l'application. Cependant, les utilisateurs publics accédant à la même application ne doivent recevoir que les permissions Lire, qui leur permettent de visualiser les pages Web de l'application sans les modifier.

Protection de Global.asa

Pour assurer la protection absolue d'une application ASP, veillez à définir les permissions NTFS accordées à l'utilisateur ou le groupe approprié pour le fichier Global.asa de votre application. Si votre Global.asa inclut des commandes qui renvoient des informations au navigateur et que vous ne protégez pas Global.asa, ces informations seront renvoyées au navigateur, même si les autres fichiers de l'application sont protégés.

Remarque Observez une certaine cohérence lorsque vous appliquez les permissions NTFS aux fichiers d'une application. Par exemple, si vous appliquez par inadvertance des permissions NTFS trop restrictives à un fichier Include nécessaire à votre application, les utilisateurs risquent de ne pas pouvoir visualiser ou exécuter cette application. Pour éviter ce genre de problèmes, mettez au point un plan très précis d'affectation de permissions NTFS à vos applications.

Permissions du serveur Web

Vous pouvez configurer les permissions de votre serveur Web afin de limiter la visualisation, l'exécution et de manipulation de vos pages ASP par tous les utilisateurs. Contrairement aux permissions NTFS, qui offrent un contrôle modulaire de la façon dont des utilisateurs spécifiques accèdent à vos fichiers et répertoirees d'applications, les permissions du serveur Web s'appliquent à tous les utilisateurs, sans qu'aucune distinction soit faite entre les différents types de comptes d'utilisateurs.

Pour permettre aux utilisateurs d'exécuter vos applications ASP, vous devez suivre les règles suivantes au moment de définir les permissions du serveur Web :

Fichiers mappés vers des scripts

Le mappage des scripts vers une application empêche votre serveur Web de télécharger accidentellement le code source d'un fichier .asp. Par exemple, même si vous définissez des permissions Lire pour un répertoire contenant un fichier .asp particulier, votre serveur Web ne renverra pas le code du fichier à l'utilisateur, du moment que le fichier .asp appartient à une application mappée vers un script.

Sécurité des cookies

ASP utilise les cookies SessionID pour suivre des informations pour des navigateurs Web spécifiques au cours de la visite d'une application, ou encore au cours d'une session. Cela signifie qu'une requête HTTP, ayant un cookie correspondant, est censée provenir d'un même navigateur Web. Votre serveur Web peut utiliser les cookies sessionID pour configurer les applications ASP en fonction d'informations personnalisées sur les sessions. Par exemple, si votre application est un point de vente d'articles musicaux en ligne qui permet aux utilisateurs de sélectionner et d'acheter des disques compacts, un SessionID peut être utilisé pour effectuer le suivi des choix de chaque utilisateur à mesure que celui-ci explore l'application.

Un pirate peut-il deviner un SessionID ?

Pour empêcher les pirates informatiques éventuels de deviner le cookie SessionID et d'accéder aux variables de session d'un utilisateur légitime, votre serveur Web affecte à chaque SessionID un numéro généré de façon aléatoire. À chaque fois que le navigateur Web de l'utilisateur renvoie un cookie SessionID, le serveur extrait le SessionID et le numéro affecté. Le serveur vérifie ensuite ce numéro en le comparant à un numéro généré, stocké exclusivement sur le serveur. Si les numéros correspondent, l'utilisateur obtient l'accès aux variables de session. L'efficacité de cette technique réside dans la longueur du numéro affecté (64 bits), qui rend très improbable la violation de la session active d'un utilisateur par un pirate informatique qui parviendrait à deviner le SessionID.

Cryptage des cookies SessionID confidentiels

Important Le cryptage SSL est disponible uniquement avec les installations Microsoft Windows NT Server de votre serveur Web.

Un pirate informatique, capable d'intercepter le cookie sessionID d'un utilisateur, peut ensuite utiliser ce cookie pour usurper son identité. Si une application ASP contient des informations personnelles, comme un numéro de carte de crédit ou de compte, le pirate s'étant approprié le cookie peut démarrer une session active sur l'application et accéder à ce type d'informations. Vous pouvez empêcher l'interception des cookies sessionID en cryptant les communications entre le serveur Web et le navigateur de l'utilisateur.

Protection de contenu ASP à accès réservé par authentification

Vous pouvez exiger de chaque utilisateur essayant d'accéder à votre contenu ASP à accès réservé, qu'il possède un nom d'utilisateur et un mot de passe valide sur un compte Windows NT. Chaque fois qu'un utilisateur tentera d'accéder à un contenu à accès réservé, votre serveur Web authentifiera, ou confirmera, l'identité de l'utilisateur afin de garantir que celui-ci possède un compte Windows NT valide.

Votre serveur Web prend en charge plusieurs méthodes d'authentification, notamment :

Néanmoins, votre serveur Web n'authentifiera les utilisateurs que si vous désactivez l'accès anonyme ou si celui-ci est restreint par les permissions NTFS.

Protection de la métabase

Les scripts ASP accédant à la métabase exigent des privilèges d'administration sur la machine sur laquelle votre serveur Web s'exécute. Lorsque vous exécutez ces scripts à partir d'une machine distante, vous devez vous connecter via une connexion authentifiée, telle qu'une connexion utilisant la méthode d'authentification Stimulation/réponse de Windows NT. Vous devez créer un serveur ou répertoire pour vos fichiers .asp d'administration et affecter à la méthode d'authentification de sécurité du répertoire la valeur Stimulation/réponse de Windows NT pour ce serveur ou répertoire. Actuellement, seul Microsoft Internet Explorer, version 2.0 ou ultérieure, prend en charge l'authentification Stimulation/réponse de Windows NT.

Protection d'applications avec SSL

Important L'authentification de certificats de clients SSL n'est disponible que pour les installations du serveur Web sous Microsoft Windows NT Server.

Le protocole SSL (Secure Sockets Layer) 3.0, implémenté comme fonctionnalité de sécurisation d'un serveur Web, assure l'établissement sécurisé extrêmement fiable d'une liaison de communication avec les utilisateurs. Ce protocole garantit l'authenticité du contenu Web et vérifie de manière très fiable l'identité des utilisateurs souhaitant accéder à des sites Web à accès réservé.

Avec le protocole SSL, vous pouvez exiger des utilisateurs tentant d'accéder à votre application ASP qu'ils établissent une liaison de communication cryptée avec votre serveur, ce qui empêche l'interception d'informations confidentielles échangées entre l'utilisateur et l'application.

Protection des fichiers joints

Si vous joignez un fichier résidant dans un répertoire protégé par le protocole SSL à partir d'un fichier .asp qui réside au niveau d'une racine virtuelle non sécurisée, le protocole SSL ne s'applique pas au fichier joint. Pour être sûr de l'application du protocole SSL, vérifiez que le fichier qui joint et le fichier joint résident tous deux dans des répertoires protégés par le protocole SSL.

Authentification par certificat client

Une façon très sûre de contrôler l'accès à vos application ASP consiste à demander aux utilisateur de se connecter avec un certificat client. Les certificats client constituent une méthode d'identification numérique contenant des informations sur l'identité de l'utilisateur et remplissent le même rôle que les identifications classiques que sont par exemple un passeport ou un permis de conduire. Les utilisateurs obtiennent en général les certificats client auprès d'organisations tierces dignes de confiance qui vérifient les informations d'identification avant d'émettre un certificat. (Le plus souvent, ces organisations demandent nom, adresse, numéro de téléphone et nom de société, mais la nature et le nombre de ces informations peuvent varier selon le niveau de fiabilité requis.)

À chaque fois qu'un utilisateur tente de se connecter à une application exigeant un certificat, son navigateur Web transmet automatiquement le certificat au serveur. Si les fonctions SSL de mappage de certificat de votre serveur Web sont correctement configurées, votre serveur peut authentifier l'utilisateur avant de lui permettre d'accéder à une application ASP.

Scripts ASP de traitement des certificats

En tant que développeur d'applications ASP, vous pouvez écrire des scripts pour confirmer la présence de champs de certificats et de champs de certificats lus. Par exemple, vous pouvez accéder aux champs du nom de l'utilisateur ou du nom de la société à partir du certificat. ASP stocke les informations sur les certificats dans la collection ClientCertificate de l'objet Request.

Avant de pouvoir traiter les certificats client avec ASP, il convient cependant de configurer votre serveur Web de manière à ce qu'il exige un certificat de client, sinon la collection ClientCertificate restera vide.

Écriture d'applications pour plusieurs plates-formes

Les applications ASP peuvent fonctionner sur des ordinateurs exécutant Windows NT 4.0 et Windows 95, ou des versions ultérieures. En outre, une version rationalisée d'ASP est disponible sur Macintosh. Étant donné que le Serveur Web personnel, aussi bien pour Windows 95 que pour Macintosh, est destiné à la publication personnelle, il existe certaines différences en matière de gestion des applications ASP. Vous pouvez facilement exécuter des applications, développées à l'aide de plates-formes de publication personnelle, sur des serveurs exécutant Windows NT Workstation ou Windows NT Server. Cette rubrique décrit certaines différences entre les plates-formes.

ASP sur Macintosh

La version Macintosh d'ASP est destinée à la publication personnelle et fournit une interface plus simplifiée pour l'écriture de scripts ASP. Par conséquent, certaines des caractéristiques d'ASP pour les plates-formes Windows ne sont pas disponibles sur Macintosh. Pour plus d'informations, consultez la documentation ASP sur Macintosh.

La version Macintosh d'ASP fournit des objets incorporés qui ne sont pas automatiquement disponibles sur les plates-formes Windows. Les plates-formes Windows sont livrées avec des composants qui fournissent ces objets ; néanmoins, vous devez déclarer ces objets dans le fichier Global.asa de l'application, afin que vos scripts puissent s'exécuter sans modification sur les plates-formes Windows.

ASP sur Windows 95

Windows 95, ou toute version ultérieure, fait office de plate-forme de publication personnelle. Bien que l'exécution d'applications ASP soit totalement prise en charge, le Gestionnaire de serveur Web personnel ne présente pas les fonctions d'administration complexes, souvent nécessaires à un développeur Web, comme la modification de script et les expirations de session.

ASP sur Windows NT Workstation

Windows NT Workstation est une plate-forme complète de développement prenant en charge toutes les fonctions d'écriture de scripts pour ASP. L'outil d'administration par défaut, le Gestionnaire de serveur Web personnel, est destiné aux administrateurs Web qui ne sont pas des administrateurs de serveurs à temps complet. Pour le développeur Web désireux de contrôler totalement un site serveur durant les phases de développement et de test des applications ASP, le Gestionnaire des services Internet correspond à l'outil d'administration approprié. Vous pouvez exécuter le programme d'installation de Serveur Web personnel pour installer le Gestionnaire des services Internet.

Objets ASP incorporés

Active Server Pages fournit des objets incorporés facilitant le rassemblement des informations envoyées dans la requête d'un navigateur, l'envoi d'une réponse à ce navigateur et le stockage d'informations sur un utilisateur spécifique, comme les préférences individuelles. Cette rubrique décrit brièvement chaque objet.

Objet Application

L'objet Application sert à partager des informations entre tous les utilisateurs d'une application donnée.

Objet Request

L'objet Request sert à accéder à toute information transmise dans une requête HTTP. Cela inclut les paramètres transmis à partir d'un formulaire HTML utilisant soit la méthode POST, soit la méthode GET, les cookies et les certificats de client. L'objet Request vous permet également d'accéder aux données binaires envoyées au serveur, comme les fichiers téléchargés.

Objet Response

L'objet Response sert à contrôler les informations envoyées à l'utilisateur. Cela inclut l'envoi d'informations directement au navigateur, la redirection du navigateur vers une autre URL ou la définition des valeurs d'un cookie.

Objet Server

L'objet Server permet d'accéder aux méthodes et aux propriétés du serveur. La méthode la plus fréquemment utilisée est celle qui permet de créer l'instance d'un composant ActiveX (Server.CreateObject.) Les autres méthodes permettent d'appliquer des URL ou un codage HTML à des chaînes, de mapper des chemins virtuels avec des chemins physiques et de définir le délai d'expiration d'un script.

Objet Session

L'objet Session sert à stocker des informations nécessaires à la session d'un utilisateur donné. Les variables stockées dans l'objet Session ne sont pas supprimées lorsqu'un utilisateur navigue de page en page au sein d'une application ; en fait, ces variables durent tant que l'utilisateur accède aux pages de votre application. Vous pouvez également utiliser les méthodes Session pour clore explicitement une session et définir le délai d'expiration des sessions inactives.

Objet ObjectContext

L'objet ObjectContext sert à valider ou à annuler une transaction démarrée par un script ASP.

Composants ActiveX

Cette section contient une vue d'ensemble des composants ActiveX inclus avec Active Server Pages (ASP).

Les composants ActiveX sont conçus pour s'exécuter sur votre serveur Web en tant qu'éléments d'une application Web. Les composants apportent la fonctionnalité nécessaire aux applications Web, comme l'accès aux bases de données, afin de vous dispenser de créer sans cesse le code nécessaire à l'exécution de telles tâches.

Database Access

Le composant Database Access vous permet d'accéder à une base de données à partir de votre application Web. Vous pouvez alors afficher le contenu entier d'une table, permettre aux utilisateurs d'élaborer des requêtes et d'effectuer d'autres opérations liées aux bases de données, à partir des pages Web.

Ad Rotator

Le composant Ad Rotator vous permet d'afficher en alternance une série d'images, tout en fournissant un lien entre l'image affichée et une autre URL. Il vous suffit de conserver une liste de publicités dans un fichier texte ; le composant Ad Rotator les affiche en fonction des instructions spécifiées dans votre fichier de données.

Content Rotator

Le composant Content Rotator automatise le défilement de chaînes de contenu HTML sur une page Web. Chaque fois qu'un utilisateur demande la page Web, le composant Content Rotator affiche une nouvelle chaîne de contenu HTML en fonction des informations spécifiées dans le fichier Content Schedule.

Les chaînes de contenu pouvant contenir des balises HTML, vous pouvez afficher tous les types de contenu pouvant être représentés en HTML : texte, images ou liens hypertexte. Ainsi, vous pouvez utiliser ce composant pour faire défiler une liste de cotes quotidiennes ou de liens hypertexte , ou encore modifier les couleurs de texte et d'arrière-plan, chaque fois qu'une page Web est ouverte.

Browser Capabilities

Le composant Browser Capabilities vous permet d'envoyer un contenu sur mesure à un navigateur en fonction de ses capacités.

File Access

Le composant File Access fournit des objets pouvant être utilisés pour récupérer et modifier des fichiers au sein d'un système de fichiers.

Content Linking

Le composant Content Linking permet de simplifier la logique de navigation à travers les fichiers .asp d'une application. Plutôt que de conserver les références des URL dans une foule de fichiers .asp, vous pouvez spécifier l'organisation séquentielle des fichiers .asp dans un simple fichier texte facile à modifier.

Collaboration Data Objects pour Windows NT Server

Le composant Collaboration Data Objects pour NTS fournit des objets de messagerie destinés à être utilisés par les applications Web. Sa bibliothèque contribue à donner, facilement et rapidement, à votre application la possibilité d'envoyer et de recevoir des éléments de messagerie. Vous pouvez créer des objets de messagerie programmables, puis utiliser leurs propriétés et leurs méthodes pour répondre aux besoins de votre application.

MyInfo, Status, System et Tools

Les composants MyInfo, Status, System et Tools fournissent une compatibilité aux applications développées sur Macintosh et déployées sur des ordinateurs fonctionnant sous Microsoft Windows.

Page Counter

Le composant Page Counter compte et affiche le nombre d'accès à une page Web. À intervalles réguliers, ce nombre d'accès est écrit dans un fichier texte, de sorte qu'en cas de panne du serveur, les données seront préservées.

Permission Checker

Le composant Permission Checker vérifie les droits d'accès de l'utilisateur Web à un fichier ou à une page. Vous pouvez utiliser le composant Permission Checker pour personnaliser une page ASP à l'intention de différents types d'utilisateurs. Ainsi, lorsqu'une page Web contient des liens hypertexte, le composant Permission Checker peut vous servir à tester les permissions d'accès des utilisateurs aux pages Web concernées. Il vous permet également d'omettre ou de désactiver tous les liens aux pages interdites à l'utilisateur.

[ RETOUR ]