Partager via

  • Article

Inside Microsoft.comGestion et délégation de ASP.NET

Jeff Toews

L'infrastructure Web microsoft.com s'exécute dans sa quasi-totalité sous .NET Framework 2.0. L'un des défis principaux d'administration Web relevé par l'équipe d'exploitation microsoft.com concerne la configuration correcte de ASP.NET. Nous avons appris beaucoup en essayant de modifier nos paramètres à la perfection. Obtenir

des paramètres de configuration corrects nécessite une bonne connaissance des différentes sections de configuration des fichiers web.config et machine.config ainsi qu'une compréhension de la signification de ces paramètres. La bonne manière d'apprendre à utiliser les paramètres et de comprendre leur signification est de regarder des exemples. Je présenterai dans cette rubrique quelques conseils de configuration dérivés de la configuration des serveurs exécutant microsoft.com pour que vous puissiez apprendre par notre expérience.

1. Définir correctement le commutateur de compilation

Lors du déploiement des applications ASP.NET dans un environnement de production, il est important de s'assurer que personne n'a laissé par inadvertance (ou délibérément) l'attribut « compilation debug » défini sur true dans aucun fichier d'application web.config, tel qu'il l'est ici :

<compilation debug="true" />

Dans des environnements chargés contenant plusieurs applications Web à gérer, vous souhaiterez utiliser les mécanismes de contrôle de la configuration ASP.NET pour éviter que cela ne se produise. (Je donnerai plus de détails sur ce point ultérieurement.)

Il est également important de s'assurer que l'attribut de débogage spécifique à la page n'est pas défini sur true dans individual .aspx tel qu'il l'est ici :

<%@ Page debug="true" %>

Je vous rappelle que dans des environnements chargés contenant de gros volumes de publication, il est souvent irréaliste de penser que vous pourrez supprimer ce paramètre de toutes les pages .aspx avant qu'elles ne soient publiées. Vous aurez besoin d'une méthode globale pour éviter que cela ne se produise.

La compilation de votre application Web avec ce paramètre créera des fichiers binaires en version de débogage plutôt qu'en version commerciale. Votre code ne sera pas optimisé ce qui entraînera des performances plus lentes. De plus, vos requêtes ASP.NET n'expireront pas car les paramètres de débogage empêchent les expirations. L'utilisation d'une version de débogage dans un environnement de production revient à laisser la porte ouverte aux pirates !

Heureusement, Microsoft® .NET Framework 2.0 dispose d'un nouveau paramètre de déploiement pour machine.config qui demande à ASP.NET de désactiver les éléments suivants : fonctionnalités de débogage, sortie de trace et affichage des messages d'erreur de ASP.NET (en local ou à distance) quelles que soient les instructions de votre fichier web.config ou les attributs de la page spécifique. Voici à quoi il ressemble :

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

Notez que ces deux derniers avantages (désactivation de la sortie de trace et des messages d'erreur détaillés de ASP.NET à distance) sont les meilleures méthodes de sécurité que vous devriez vraiment adopter. Le cas échéant, vous exposez le fonctionnement interne de votre application au monde entier.

Puisque j'aborde le sujet, il existe un autre aspect important : le verrouillage de l'attribut debug <system.web><compilation> du fichier racine web.config dans <location allowOverride="false"> ou l'utilisation de l'attribut lockItems éviteront que les fichiers web.config situés en bas dans la hiérarchie de configuration de l'application n'activent les paramètres de débogage. Cependant, cela n'empêchera pas les pages individuelles .aspx d'activer le mode de débogage dans leurs attributs de page. Le paramètre deployment retail est la seule méthode qui permet de désactiver entièrement les fonctionnalités de débogage de ASP.NET à tous les niveaux.

La définition du paramètre deployment retail sur true est probablement la meilleure méthode à recommander à toute entreprise disposant de serveurs de production formels pour garantir l'exécution d'une application avec les meilleures performances possibles et l'absence de fuite d'informations de sécurité. Comme je l'ai dit plus haut, ce paramètre est tout nouveau dans ASP.NET 2.0 ; il est la conséquence directe de commentaires transmis à l'équipe ASP.NET.

À l'inverse, pour des environnements de pré-production internes où les développeurs doivent déboguer leurs applications Web, n'utilisez pas le paramètre deployment retail. Définissez simplement <compilation debug="false"> dans le fichier racine de pré-production web.config et autorisez le remplacement de cette valeur par des fichiers d'applications individuelles web.config ou par des attributs de page .aspx.

2. Utiliser la confiance moyenne dans ASP.NET 2.0

Si, comme c'était le cas pour plusieurs sites de microsoft.com, vous utilisiez toujours un niveau de confiance Total ou Élevé même après la migration de votre site ou d'applications vers ASP.NET 2.0, examinez de nouveau ce que permet de faire la confiance moyenne. Par exemple, une demande restreinte WebPermission limite les communications d'une application à une seule adresse ou à un ensemble d'adresses que vous définissez dans l'élément <trust>. Cela vous permet de contrôler et de conserver une liste de sites externes et d'adresses approuvés qui peuvent être appelés à distance. Il s'agit là d'un important compagnon de sécurité.

FileIOPermission est également restreint. Cela signifie qu'un code d'application peut uniquement accéder aux fichiers dans sa hiérarchie de répertoires virtuels. Par défaut dans la confiance moyenne, chaque application se voit accordée des autorisations Read, Write, Append et PathDiscovery uniquement pour sa hiérarchie de répertoires virtuels. Cela met fin à l'accès d'E/S au fichier à accès aléatoire—plutôt important dans un environnement Web partagé dans lequel plusieurs applications sont hébergées.

Un autre avantage concerne la suppression des privilèges de code non géré. Cela signifie que vous pouvez empêcher l'utilisation des composants hérités, la méthode la plus simple que nous ayons trouvé pour désactiver l'utilisation de l'attribut de page Aspcompat. (La définition de Aspcompat sur true peut dégrader les performances d'une page.)

La confiance moyenne dans ASP.NET 2.0 est assez flexible en termes de capacité offerte à l'administrateur pour créer des exceptions personnalisées sur chacune des restrictions par défaut précédentes. Cette flexibilité n'existait pas dans ASP.NET 1.1. Une autre raison expliquant que l'exécution de la confiance moyenne avec ASP.NET 2.0 est simplifiée par rapport à ASP.NET 1.1 concerne l'accès aux bases de données Microsoft SQL Server™.

Ainsi, si vous hébergez plusieurs applications sur le même serveur, vous pouvez utiliser une sécurité d'accès au code et le niveau de confiance Moyen pour fournir une isolation des applications. En définissant et en verrouillant le niveau de confiance (à l'aide des balises <location allowOverride="false">) dans le fichier racine web.config, vous pouvez établir des stratégies de sécurité pour toutes les applications Web du serveur. En définissant allowOverride="false", comme indiqué dans la figure 1, un développeur ne pourra pas remplacer le paramètre de politique de confidentialité moyenne dans son fichier d'application web.config.

Figure 1 Paramètres de confiance

<configuration>
    <location allowOverride="false">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low"  policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Medium" originUrl="" />
        </system.web>
    </location>
</configuration>

Pour obtenir plus d'informations sur l'utilisation de la confiance moyenne dans ASP.NET 2.0, consultez l'article suivant : "How to: Use Medium Trust in ASP.NET 2.0". (Comment utiliser la confiance moyenne dans ASP.NET 2.0 ?)

3. Restreindre le téléchargement de types de fichiers spécifiés

Votre serveur contient des types de fichiers dont vous ne souhaiteriez certainement pas qu'ils tombent entre de mauvaises mains. Heureusement, par défaut, ASP.NET est configuré pour intercepter et arrêter les requêtes de plusieurs types de fichiers différents utilisés dans les applications ASP.NET. Ils incluent les fichiers .config et .cs qui stockent le code source de l'application. ASP.NET garantit la confidentialité de ces fichiers en associant les types de fichiers à System.Web.HttpForbiddenHandler. Ce gestionnaire, lorsqu'il est appelé, renvoie une erreur à l'utilisateur qui demande le fichier. En fait, vous pouvez utiliser cette méthode pour restreindre tout type de fichier.

Par exemple, sur le site microsoft.com, le type de fichier .asmx peut être interdit en ajoutant l'entrée suivante à la section <system.web><httpHandlers> du fichier racine web.config :

<add path="*.asmx" verb="*" type=
    "System.Web.HttpForbiddenHandler" />

Comme vous pouvez le voir, vous pouvez utiliser les sous-balises <add> dans l'élément <httpHandlers> pour indiquer les types de fichiers supplémentaires que vous souhaitez bloquer. Définissez l'attribut verb sur « * ». Lors de cette opération, vous indiquez que tous les types de requêtes HTTP sont bloquées pour ce type de fichier. Définissez l'attribut path en tant que caractère générique correspondant aux types de fichiers que vous souhaitez bloquer. Par exemple, vous pouvez spécifier « *.mdb ». Enfin, définissez l'attribut du type sur « System.Web.HttpForbiddenHandler ».

4. Être prudent lors de l'ajout de références d'assembly

Chaque serveur Web qui exécute .NET Framework dispose d'un cache du code de l'ordinateur appelé cache d'assembly global (GAC, Global Assembly Cache). Le GAC stocke les assemblys particulièrement destinés à être partagés par plusieurs applications sur l'ordinateur. Il paraît logique d'ajouter des assemblys au GAC si plusieurs applications différentes doivent les référencer, même si la majorité des sites du serveur Web n'y ont pas accès. Ce processus n'entraîne pas de pénalités en termes de performances/ressources significatives mais a l'avantage de maintenir un contrôle de version centralisé plutôt que d'avoir des assemblys partagés disséminés sur le serveur dans des dossiers d'application individuels /bin.

Cependant, le critère de l'intervalle auquel une référence d'assembly doit être ajoutée au fichier racine web.config doit être plus strict que le critère imposant l'intervalle auquel un assembly est placé dans le GAC. Dans les applications individuelles, l'ajout de références d'assembly à leur fichier d'applications web.config pour des composants qui ne sont pas vraiment globaux donne de meilleurs résultats que de déclarer ces références d'assembly dans le fichier racine web.config. Cela réduit le temps de chargement de la page de manière significative pour toutes les applications d'un serveur Web qui n'utilisent pas ces assemblys car le compilateur ne perd pas son temps à charger des assemblys inutiles. Le compilateur ASP.NET ne chargera aucun assembly pour une application simplement parce que l'assembly réside dans le GAC ; il le lira uniquement si une référence d'assembly existe dans son domaine d'application ou dans une étendue d'application plus importante. Par conséquent, chez microsoft.com, nous autorisons les développeurs d'applications à remplacer l'élément <configuration><system.web><compilation><assemblies> dans leur fichier d'applications web.config pour tous les environnements Microsoft.com.

En particulier, dans les fichiers racine web.config d'environnements de déploiement et de production de microsoft.com, tous les attributs du nœud <system.web><compilation> sont verrouillés (y compris debug, explicit, defaultLanguage) ainsi que tous ses éléments (buildProviders, expressionBuilders, etc.), sauf l'élément <assemblies> :

<compilation debug="false" 
    explicit="true" defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAttributes="*" lockAllElementsExcept=
        "assemblies" >

Dans l'environnement de pré-production interne, la section <system.web><compilation> est verrouillée dans le fichier racine web.config, mais nous autorisons les éditeurs d'applications à remplacer spécifiquement l'élément <assemblies> ainsi qu'à remplacer debug="false" (pour activer le dépannage/débogage) :

<compilation debug="false" explicit="true"
    defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAllAttributesExcept="debug" 
    lockAllElementsExcept="assemblies" >

Notez ici l'utilisation des attributs lock, qui sont nouveaux dans ASP.NET 2.0. Je vous rappelle que vous trouverez des informations détaillées sur ces attributs et des exemples de leur utilisation dans la section « Attributs généraux hérités par les éléments de section ».

5. Supprimer manuellement les valeurs Set MaxConnection

À peu près tous les sites Web microsoft.com disposent d'applications ASP.NET qui établissent des appels pour se connecter aux clusters des services Web. Le nombre maximal d'appels simultanés de services Web à distance qui peuvent être établis à partir d'un serveur Web unique est déterminé par l'attribut maxConnection de l'élément <connectionManagement> dans le fichier machine.config. Dans ASP.NET 1.1, la valeur de maxConnection est définie par défaut sur 2. Cette ancienne valeur de maxConnection par défaut était beaucoup trop faible pour des sites tels que microsoft.com dans lesquels des centaines d'applications différentes établissent des appels de services Web à distance. Par conséquent, les demandes ASP.NET se retrouvaient dans la file d'attente en attendant que les appels de services Web à distance se terminent. (Vous pouvez visualiser le nombre de demandes ASP.NET en attente via le compteur de l’Analyseur de performances ASP.NET\Demandes en attente.) Pour établir plus d'appels simultanés sur un service Web à distance (et ainsi améliorer les performances des applications sur le site), nous avons augmenté la valeur de maxConnection à 40 pour nos serveurs Web à quatre processeurs. (La valeur générale recommandée pour maxConnection correspond à 12 fois le nombre de processeurs, à optimiser pour correspondre à votre situation spécifique.)

Cependant dans ASP.NET 2.0, vous n'avez plus besoin de configurer la valeur de maxConnection manuellement puisqu'elle est désormais automatiquement mise à l'échelle et définie. Et ce grâce à la nouvelle section de configuration de la balise processModel dans machine.config (pour plus d'informations sur l'élément processModel, voir « Élément processModel (Schéma des paramètres ASP.NET)) ».

<system.web>
    <processModel autoConfig="true" />
</system.web>

Avec autoConfig activé dans machine.config (il s'agit du paramètre par défaut), ASP.NET définit la valeur du paramètre maxConnection sur 12n (où n est le nombre de processeurs). L'activation de autoConfig entraîne également les modifications suivantes : les paramètres maxWorkerThreads et maxIoThreads sont définis sur 100, le paramètre minFreeThreads est défini sur 88n, le paramètre minLocalRequestFreeThreads est défini sur 76n et minWorkerThreads sur 50.

Avant d'utiliser autoConfig dans ASP.NET 2.0 pour mettre à l'échelle et définir automatiquement les valeurs de maxConnection et les autres attributs de la liste, assurez-vous de supprimer toute valeur définie manuellement pour ces paramètres car ces valeurs seraient utilisées à la place des valeurs autoConfig. Vous devez vous en souvenir lors de la migration depuis ASP.NET 1.1 (où maxConnection doit être définie explicitement) vers ASP.NET 2.0, qui comporte des valeurs par défaut.

De nouveau, les valeurs autoConfig de maxConnection et les autres attributs répertoriés précédemment sont plutôt arbitraires et peuvent ne pas fonctionner pour chaque instance ; j'ai cependant constaté que ces limitations fonctionnaient bien pour à peu près toutes les applications microsoft.com.

Si vous décidez de régler la valeur maxConnection manuellement, soyez prudent car une augmentation de sa valeur peut augmenter l'utilisation du processeur. Cette augmentation est provoquée par le fait qu'un nombre plus grand de demandes peut être effectué par ASP.NET au lieu d'attendre leur tour pour appeler le service Web. Bien entendu, vous devriez vous rappeler que l'attribut maxConnection n'affecte pas les appels locaux de services Web mais uniquement les appels à distance.

6. Se méfier des exceptions non prises en charge

Lors du portage de sites Web ou d'applications ASP.NET 1.1 vers ASP.NET 2.0, il est extrêmement utile de prendre en considération un changement important de la stratégie par défaut pour les exceptions non prises en charge. Dans .NET Framework 1.1 et 1.0, les exceptions non prises en charge sur des threads gérés ont été ignorées et, parce que les applications ont continué à s'exécuter, ces exceptions sont souvent restées masquées. Même en ayant connecté un débogueur pour intercepter l'exception, vous ne vous seriez pas rendu compte que quelque chose n'allait pas. Sous ASP.NET 2.0, toutefois, lorsqu'une exception non prise en charge est levée, l'application ASP.NET se ferme de manière inattendue. Cela peut sérieusement avoir un impact sur la disponibilité de votre site ou de l'application s'il existe un grand nombre d'exceptions non prises en charge précédemment traitées par l'ancienne stratégie de traitement des exceptions par défaut.

La meilleure façon de procéder consiste à effectuer des tests approfondis et d'éliminer les exceptions non prises en charge (qui ne devraient pas se trouver dans votre application). Cependant, pour des migrations d'applications très volumineuses dans lesquelles il peut être difficile de déterminer où l'exception s'exécute ou si vous devez migrer un grand nombre d'applications héritées pour lesquelles il est impossible d'effectuer un test individuel approfondi, vous disposez de plusieurs options. Lors de la migration du site Web microsoft.com vers ASP.NET 2.0, nous avons redéfini la stratégie des exceptions non prises en charge sur le comportement par défaut utilisé dans ASP.NET 1.1 et ASP.NET 1.0.

Pour activer ce comportement de traitement des exceptions par défaut hérité, ajoutez le code suivant au fichier aspnet.config :

<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy 
            enabled="true" />
    </runtime>
</configuration>

Le code se trouve dans l'un des deux dossiers suivants :

%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (sur les systèmes x86 ou SYSWOW64) et %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (sur les systèmes x64).

Cette modification ne fera que redéfinir .NET Framework sur l'ancien comportement 1.1 et 1.0. Considérez qu'il s'agit d'un correctif à court terme car au final, il masque les problèmes de votre application qui sont réellement des bogues. Cependant, c'est une méthode très pratique pour éviter les problèmes de disponibilité dus aux processus de travail achevés de manière inattendue. Pour plus d'informations sur la modification de ce comportement, voir « Les exceptions non prises en charge provoquent la fermeture inattendue des applications ASP.NET sous .NET Framework 2.0 ».

7. Garantir une configuration correcte du serveur proxy

Un administrateur de serveur Web peut spécifier le serveur proxy à utiliser pour les requêtes HTTP sur Internet en configurant l'élément <configuration><system.net><defaultProxy> dans le fichier machine.config.

Dans l'environnement de production microsoft.com, nous configurons la valeur <defaultProxy> pour utiliser le proxy par défaut du système (puisque le client de pare-feu n'est pas installé) et nous utilisons les balises <location allowOverride="false"> pour empêcher l'élément <defaultProxy> d'être remplacé par les développeurs d'applications (qui pourraient publier un fichier web.config avec un serveur proxy interne par inadvertance) :

<configuration>
    <location allowOverride="false">
       <system.net>
          <defaultProxy>
              <proxy usesystemdefault="true" />
          </defaultProxy>
       </system.net>
    </location>
</configuration>

Dans les environnements de déploiement et de pré-production internes de microsoft.com, nous définissons l'attribut usesystemdefault sur false, bypassonlocal sur true et ajoutons un attribut bypasslist de proxy (voir figure 2). L'attribut bypasslist répertorie les expressions régulières qui décrivent les adresses n'utilisant pas le proxy spécifié. De nouveau, cette section se trouve dans les balises <location allowOverride="false"> et permet d'empêcher les développeurs de spécifier leur propre serveur proxy dans leurs fichiers web.config. (Ces serveurs proxy sont souvent internes et les appels dirigés vers eux échouent lorsque les pages sont publiées en production.) Toute tentative de spécification d'un serveur proxy en pré-production ou en déploiement provoquera une erreur ASP.NET lors de l'exécution, ce qui forcera les développeurs à supprimer cette configuration avant de publier en production.

Figure 2 Définition de Bypasslist

<configuration>
    <location allowOverride="false">
        <system.net>
             <defaultProxy>
                <proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />

                <bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
                </bypasslist>
            </defaultProxy>
        </system.net>
    </location>
</configuration>

8. Ne pas révéler les erreurs personnalisées à tout le monde

Comme je l'ai précisé, il est important de ne pas autoriser les messages d'erreur ASP.NET détaillés à être renvoyés à distance par les serveurs Web dans l'environnement de production.

Dans les fichiers racine web.config de l'environnement de déploiement et de production microsoft.com, l'attribut mode <configuration><system.web><customErrors> est défini sur RemoteOnly pour que les erreurs personnalisées s'affichent sur les clients distants et que les erreurs ASP.NET s'affichent sur l'hôte local (pour autoriser le dépannage par les administrateurs de serveurs Web). Notez que l'élément <customErrors> se trouve dans une balise <location> avec allowOverride="false" (voir figure 3). Il s'agit d'empêcher les propriétaires de l'application individuelle de définir par inadvertance (ou délibérément) mode="Off" et de révéler les messages d'erreur ASP.NET détaillés sur Internet.

Figure 3 Empêcher l'affichage des messages d'erreur

&lt;configuration&gt;
    &lt;location allowOverride='false'&gt;
        &lt;system.web&gt;
            &lt;customErrors mode='RemoteOnly' defaultRedirect=
                   '/errorpages/generic_customerror.aspx'&gt;
                &lt;error statusCode='404' redirect='/errorpages/filenotfound_customerror.aspx' /&gt;
            &lt;/customErrors&gt;
        &lt;/system.web&gt;
    &lt;/location&gt;
&lt;configuration&gt;

De même, n'oubliez pas, comme je l'ai expliqué précédemment, que l'utilisation du paramètre <deployment retail="true"/> dans le fichier machine.config désactive la fonctionnalité d'affichage des messages d'erreur ASP.NET détaillés sur les clients distants et locaux. Ce paramètre deployment retail devrait toujours constituer votre méthode primaire de désactivation de ces messages d'erreur si vous exécutez ASP.NET 2.0. (Pour obtenir des informations détaillées sur les exceptions ASP.NET, utilisez le journal des événements de l'application.)

Dans le fichier racine web.config de l'environnement de pré-production interne de microsoft.com, l'attribut mode <customErrors> est défini sur off pour que les erreurs ASP.NET soient toujours affichées sur les clients distants et l'hôte local. Cela permet d'activer le débogage et le dépannage. De plus, aucune page d'erreur personnalisée n'est configurée :

<configuration>
    <location allowOverride="false">
        <system.web>
            <customErrors mode="Off" />
        </system.web>
    </location>
<configuration>

9. Savoir à quel moment activer le suivi

Les traces ASP.NET sont générées lors de l'exécution d'une page ASP.NET et capturent des détails intéressants sur la demande Web, l'arborescence des contrôles de la page et l'exécution des différentes étapes du cycle de vie et des contrôles de la page. De plus, les messages personnalisés qui peuvent être écrits sur la trace par le développeur de la page peuvent être affichés. La trace peut être ajoutée à la sortie de réponse de la page en cours de suivi ou examinée dans la liste des demandes suivies de la visionneuse de traçage de l'application. Cette fonctionnalité est principalement destinée aux scénarios de débogage du temps de développement dans les environnements de pré-production internes et ne devrait pas être utilisée pour les déploiements de production.

Dans les fichiers racine web.config des environnements de déploiement et de production microsoft.com, l'attribut enabled <configuration><system.web><trace> est défini sur « false » pour que la fonctionnalité de sortie des informations de trace d'une page Web soit désactivée. Notez que l'élément <trace> se trouve dans une balise <location> avec allowOverride="false". Il s'agit d'empêcher les propriétaires d'applications individuelles de définir par inadvertance (ou délibérément) enabled="true" et de révéler les informations de traçage détaillées ASP.NET sur Internet :

<configuration>
    <location allowOverride="false">
        <system.web>
              <trace enabled="false" localOnly="true"
              pageOutput="false" requestLimit="10" traceMode="SortByTime" />
        </system.web>
    </location>
<configuration>

<system.web><trace>

Comme indiqué plus haut, l'utilisation du paramètre <deployment retail="true"/> dans le fichier machine.config désactive également la fonctionnalité permettant de révéler une sortie de trace ASP.NET sur une page Web. Ce paramètre devrait toujours constituer votre méthode primaire de désactivation d'une sortie de traçage si vous exécutez .NET Framework 2.0.

Pour être totalement sûr que le traçage ne peut être activé par inadvertance dans des environnements de production externes, chez microsoft.com, nous supprimons le gestionnaire réel trace.axd du fichier racine web.config ou indiquons un commentaire, comme suit :

<!--
<add path="trace.axd" verb="*" type=
    "System.Web.Handlers.TraceHandler"
    validate="True" />
-->

10. Désactiver les groupes de serveurs Web d'état de session

Étant donné que tous les sites Web de microsoft.com sont actuellement clusterisés à l'aide de l'équilibrage de la charge réseau (NLB, Network Load Balancing) sans aucune affinité (pour permettre la distribution des demandes sur tous les serveurs du cluster), rien ne garantit que le même serveur va gérer toutes les demandes d'une application donnée. Par conséquent, le module d'état de session ASP.NET est désactivé pour empêcher l'utilisation de la propriété Session par les développeurs d'applications. Le conseil que nous donnons aux développeurs d'applications qui doivent gérer l'état est d'utiliser l'état d'affichage (qui gère l'état d'une structure dans le code de la page et n'utilise donc aucune ressource de serveurs).

Pour désactiver l'état de session sur un serveur Web, vous devriez simplement supprimer le nœud enfant suivant du nœud <httpModules> :

<add name="Session" type=
    "System.Web.SessionState.
    SessionStateModule"/>

J'ai supposé ici que vous aviez déjà vu et même utilisé les fichiers de configuration ASP.NET (machine.config, root web.config et fichiers d'applications individuelles web.config), le cas échéant, le Didacticiel de démarrage rapide ASP.NET suivant vous aidera : asp.net/QuickStart/aspnet/doc/management/fileformat.aspx.

L'article mentionne que le système de configuration ASP.NET 2.0 inclut à présent plusieurs fonctionnalités très utiles permettant aux administrateurs de verrouiller des éléments individuels et des attributs de configuration, à l'aide des attributs lockItems et lockCollections. Ces attributs ainsi que leur utilisation sont décrits dans l'article intitulé « Attributs généraux hérités par les éléments de section ».

Jeff Toews est responsable de l'ingénierie des systèmes et fut membre de l'équipe d'exploitation Microsoft.com, basée à Redmond, WA, pendant six ans. Pour toute question technique ou tout commentaire, vous pouvez le contacter à l'adresse mscomblg@microsoft.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.