Share via

Étape de planification 2 : Planifier les paramètres de ASP.NET

  • Article

par Keith Newman et Robert McMurray

2.1. Paramètres d'état de session

Quand des clients visitent un site, ils naviguent généralement d'une page à une autre et modifient fréquemment certaines des pages qu'ils consultent. Si vous souhaitez effectuer le suivi des pages parcourues par les utilisateurs et des modifications qu'ils apportent au cours de leur visite sur votre site web, vous devez configurer l'état de session.

Quand l'état de session est activé pour votre application, un utilisateur reçoit un ID de session unique lors de sa première demande à une page web à partir de votre application ASP.NET. Les données d'état de session sont stockées sur le serveur de l'une des manières suivantes :

  • in-process : l’état de session est stocké dans le processus de travail où s’exécute l’application ASP.NET.
  • Serveur d’état: l’état de session est stocké en dehors du processus de travail où s’exécute l’application ASP.NET.
  • SQL Server: l’état de session est stocké dans une base de données SQL Server.

Remarque

Vous pouvez également configurer le stockage hors état personnalisé pour les données d'état de session. Toutefois, cet aspect dépasse le cadre de ce didacticiel. Les projets Visual Studio 11 utilisent le stockage personnalisé pour prendre en charge SQL Server, SQL Compact et SQL Azure.

Les données d'état de session peuvent également être stockées sur le client dans un cookie. Un cookie est un fichier texte qui contient des données servant à stocker des informations relatives à un utilisateur, telles que les préférences de l'utilisateur et les informations d'authentification utilisateur.

Les sections suivantes décrivent plus en détail les options de stockage de l'état de session disponibles.

Stocker l'état de session dans un processus

Le mode d'état de session in-process stocke les données d'état de session pour une application ASP.NET dans le processus de travail qui exécute l'application. Ce mode est la valeur par défaut pour IIS 8.

L'avantage de l'état de session in-process est qu'il fournit l'accès le plus rapide aux données d'état de session. Toutefois, à mesure que vous stockez des données dans une session, vous consommez davantage de mémoire, ce qui peut ralentir les performances du serveur.

Avant de configurer l'état de session in-process, vous devez prendre en compte l'effet du recyclage de processus de travail sur les données d'état de session. Si le processus de travail est recyclé, toutes les données d'état de session sont perdues. Si vos applications ASP.NET doivent conserver les données d'état de session et si la rapidité d'accès aux données n'est pas votre objectif principal, vous pouvez utiliser un mode d'état de session hors processus pour stocker ces données.

Important

Le service d'état Windows (Aspnet_state.exe) doit être en cours d'exécution pour que l'état de session in-process prenne effet. Par défaut, ce service est installé lorsque Windows Server® 2012 est installé et configuré pour le démarrage manuel. Nous vous recommandons de définir le comportement de démarrage sur Automatique.

Par défaut, la session expire quand l'utilisateur n'a pas demandé ou actualisé une page dans l'application ASP.NET depuis 20 minutes. Les objets de session consommant de la mémoire sur le serveur web, vous pouvez diminuer la valeur de délai d'expiration pour préserver les ressources.

Important : procédez avec caution lors de la modification de la valeur de délai d'expiration de session, car les informations stockées dans l'objet de session d'un utilisateur sont perdues quand celui-ci n'est pas actif sur le site web pendant la durée de la période de délai d'expiration.

Si vous décidez d'utiliser le stockage d'état de session in-process, vous devez décider si vous souhaitez également utiliser des cookies. Pour plus d'informations sur les cookies, voir Mode de cookie pour l'état de session.

Stocker l'état de session à l'aide du serveur d'état

Un serveur d'état conserve les données d'état de session dans une mémoire en dehors du processus de travail. L'avantage de cette configuration est que l'état de session est conservé quand le processus de travail de l'application est recyclé. L'utilisation d'un serveur d'état est recommandé pour les applications de taille moyenne.

Un serveur d'état dépend du service d'état de Windows (Aspnet_state.exe) et nécessite une clé d'ordinateur pour vérifier l'état de session via la connexion.

Quand un serveur d'état s'exécute sur le serveur web qui contient les applications pour lesquelles il conserve l'état, une configuration de domaine privé web est prise en charge. Pour bénéficier d'une protection renforcée des données d'état de session, utilisez une configuration de batterie de serveurs web avec un serveur distinct qui stocke l'état de session et le partage parmi tous les serveurs de la batterie. Une autre approche consiste à utiliser SQL server pour tenir à jour l'état de session out-of-process.

Important : le service d'état Windows (Aspnet_state.exe) doit être en cours d'exécution pour que l'état de session in-process prenne effet. Par défaut, ce service est installé lorsque Windows Server 2012 est installé et configuré pour le démarrage manuel. Sélectionnez le comportement de démarrage Automatique.

Si vous décidez de stocker l'état de session à l'aide d'un serveur d'état, vous devez prendre les décisions de conception suivantes :

  • Définissez une chaîne de connexion pour le serveur d'état.
  • Spécifiez le nombre de secondes avant le délai d'expiration de connexion.
  • Déterminez s’il faut activer la compression.
  • Décidez si vous souhaitez stocker les données d'état de session dans un cookie. Pour plus d'informations sur les cookies, voir Mode de cookie pour l'état de session.

Stocker l'état de session à l'aide de SQL Server

L'un des types d'état de session out-of-process utilise un serveur SQL Server pour stocker les données d'état de session. L'avantage de cette configuration est que l'état de session est conservé en dépit du recyclage du processus de travail de l'application, ou si le service d'état de Windows ou le serveur web tombe en panne.

Remarque

Ce paramètre ne prend pas en charge SQL Azure.

Quand un serveur SQL Server s'exécute sur le serveur web qui contient les applications pour lesquelles il conserve l'état, il prend en charge une configuration de domaine privé web, ce qui augmente l'évolutivité du serveur web. Lorsque le serveur SQL s’exécute sur un autre serveur, il prend en charge une configuration de batterie de serveurs web, ce qui augmente considérablement l’extensibilité entre un groupe de serveurs.

Important

Le service d’état Windows (Aspnet_state.exe) doit être en cours d’exécution pour que l’état de session hors processus prenne effet. Par défaut, ce service est installé lorsque Windows Server 2012 est installé et configuré pour le démarrage manuel. Sélectionnez le comportement de démarrage Automatique.

Important

Avant de configurer un serveur SQL pour l’état de session, exécutez le script InstallSqlState.sql sur le serveur. Par défaut, ce script est stocké dans %systemroot%\Microsoft.NET\Framework\V4.0.30319.

Si vous décidez de stocker l'état de session dans une base de données SQL Server, vous devez prendre les décisions de conception suivantes :

  • Définissez une chaîne de connexion pour la base de données.
  • Spécifiez le nombre de secondes avant le délai d'expiration de connexion.
  • Spécifiez le nombre de secondes qui doivent s'écouler avant d'essayer de se reconnecter.
  • Décidez si vous souhaitez activer une base de données personnalisée.
  • Déterminez s’il faut activer la compression.
  • Décidez si vous souhaitez stocker les données d'état de session dans un cookie. Pour plus d'informations sur les cookies, voir Mode de cookie pour l'état de session.

L'une des manières d'effectuer le suivi de l'état de session pour les clients qui se connectent à un serveur web consiste à utiliser des cookies. Vous pouvez configurer un serveur web pour utiliser des cookies, ne pas utiliser de cookies ou sélectionner le comportement des cookies qui dépend du navigateur utilisé pour la connexion.

Un cookie de session associe les informations de session aux des informations sur le client pour la session. Une session est la durée de la connexion d’un utilisateur à un site. Le cookie est transmis avec toutes les requêtes entre un client et un serveur web dans un en-tête HTTP.

L’utilisation de cookies pour suivre l’état de session est plus efficace que toute autre méthode qui n’utilise pas de cookies, car les cookies ne nécessitent aucune redirection. En outre, ils permettent aux utilisateurs de mettre en signet des pages web, et ils conservent l’état si un utilisateur quitte un site pour visiter un autre, puis retourne au site d’origine. Le principal inconvénient des cookies utilisateur est que les utilisateurs peuvent désactiver les cookies dans leur navigateur.

Le mode de cookie Utiliser le profil d’appareil entraîne l’utilisation des cookies par le navigateur si le navigateur prend en charge les cookies ; sinon, aucun cookie n’est utilisé. Si le profil de périphérique indique la prise en charge des cookies, ils sont utilisés même si l'utilisateur a désactivé la prise en charge des cookies.

Important

Lorsque vous utilisez le mode de cookie Utiliser le profil d’appareil, définissez les ID de session expirés à régénérer. Cela permet à un serveur web d'expirer et de regénérer les jetons. Ainsi, un agresseur potentiel dispose de moins de temps pour capturer un cookie et accéder au contenu du serveur web.

Le mode de détection automatique de cookie entraîne l’utilisation des cookies par l’appareil mobile si son profil prend en charge les cookies ; sinon, aucun cookie n’est utilisé. Pour les navigateurs de bureau qui prennent en charge les cookies, ASP.NET essaie d'utiliser les cookies quand la prise en charge des cookies est activée dans le navigateur. Si la prise en charge des cookies est désactivée, l'état de session est stocké dans l'URL.

Important

Lorsque vous utilisez le mode de cookie Détection automatique, définissez les ID de session expirés à régénérer. Cela permet à un serveur web d'expirer et de regénérer les jetons. Ainsi, un agresseur potentiel dispose de moins de temps pour capturer un cookie et accéder au contenu du serveur web. Vous pourriez également réduire la valeur de délai d'expiration (qui, par défaut, est de 20 minutes).

Vous pouvez configurer l'état de session sans utiliser de cookies. Lorsque vous utilisez un URI (Uniform Resource Identifier) pour gérer l’état de session, l’ID de session est incorporé en tant que chaîne de requête dans la requête URI, puis l’URI est redirigé vers l’URL demandée à l’origine. La demande URI modifiée est utilisée pour la durée de la session. Aucun cookie n'est donc nécessaire.

Important

Lorsque vous utilisez un URI, définissez les ID de session expirés à régénérer. Cela permet à un serveur web d'expirer et de regénérer les jetons. Ainsi, un agresseur potentiel dispose de moins de temps pour capturer un cookie et accéder au contenu du serveur web.

L’utilisation d’un URI pour suivre l’état de session peut vous aider à éviter les inconvénients des cookies, notamment les problèmes de prise en charge du navigateur et la possibilité pour les utilisateurs de désactiver les cookies. Toutefois, l’utilisation d’un URI présente les inconvénients suivants :

  • Impossible d’utiliser des URL absolues sans perdre l’état de session, ce qui signifie que si un utilisateur accède à une autre application, puis retourne à la précédente, l’entrée de l’utilisateur n’existe plus sur la page.
  • Les utilisateurs ne peuvent pas créer de signets pour les pages web, car l'état de session est perdu.

Si vous décidez d'utiliser des cookies pour stocker l'état de session, vous devez prendre les décisions de conception suivantes :

  • Sélectionnez un mode de cookie : détection automatique, utiliser les cookies, utiliser le profil de périphérique ou utiliser un URI.
  • Spécifiez le nom du cookie (sauf si vous avez sélectionné l'utilisation d'un URI).
  • Spécifiez le nombre de minutes avant que le cookie expire (sauf si vous avez sélectionné l'utilisation d'un URI).
  • Sauf si vous avez sélectionné utiliser des cookies, décidez s’il faut régénérer un ID de session expiré.

2.2. Paramètres de pages et de contrôles

Les pages ASP.NET comportent des éléments supplémentaires qu'ASP.NET reconnaît et traite quand la page s'exécute. Les pages ASP.NET peuvent également contenir des contrôles personnalisés et réutilisables. Ces contrôles personnalisés sont traités sur le serveur. Cela vous permet d'utiliser du code serveur pour définir des propriétés de page web ASP.NET.

Remarque

Ces paramètres appliquent uniquement les ASP.NET Web Forms. Elles ne s’appliquent pas aux pages web ASP.NET MVC ou ASP.NET.

IIS 8 vous permet de configurer les paramètres suivants de la page ASP.NET et des contrôles utilisateur :

  • Paramètres de comportement : par exemple, si la page web conserve son état d’affichage et l’état d’affichage des contrôles serveur qu’elle contient lorsque la demande de page active se termine.
  • Paramètres généraux : par exemple, les espaces de noms inclus pour toutes les pages.
  • Paramètres de compilation : par exemple, si les pages sont compilées ou interprétées.
  • Services : par exemple, si l’état de session est activé.

IIS 8 fournit des paramètres par défaut pour les pages et contrôles ASP.NET, mais vous pouvez modifier ces paramètres en fonction des besoins. Par exemple, vous pouvez définir le fichier de page maître pour un site ou activer l'état d'affichage.

Les contrôles web personnalisés sont des composants compilés qui s'exécutent sur le serveur et qui encapsulent l'interface utilisateur et d'autres fonctionnalités associées dans des packages réutilisables. Dans IIS 8, vous pouvez spécifier le préfixe de balise et le mappage d’espace de noms pour un contrôle personnalisé qui peut être utilisé dans plusieurs pages d’une application.

Ajoutez un contrôle personnalisé lorsque vous souhaitez spécifier le mappage de préfixe/d’espace de noms d’étiquette pour un contrôle personnalisé utilisé dans plusieurs pages d’une application.

Remarque

L’ajout d’un paramètre de configuration ajoute le paramètre au niveau local et aux niveaux enfants qui héritent du paramètre.

Si vous décidez de configurer les contrôles personnalisés ASP.NET, vous avez besoin des informations suivantes pour chaque contrôle que vous souhaitez configurer :

  • Vous avez spécifié le préfixe de balise du contrôle.
  • Spécifiez l’espace de noms .NET du contrôle.
  • Vous avez spécifié l'assembly dans lequel figure le contrôle.

2.3. Paramètres de l’application

Configurez les paramètres d'application quand vous voulez stocker des paires clé/valeur dans le cadre de votre configuration dans le fichier Web.config. Les paramètres d’application fournissent un accès rapide et facile aux données de configuration stockées pour votre application.

Pour gérer les contrôles personnalisés, vous pouvez afficher une liste qui contient tous les contrôles personnalisés pour un niveau de configuration particulier. Vous pouvez trier cette liste par préfixe d’étiquette, source ou assembly, ou étendue (local ou hérité). Vous pouvez également regrouper les contrôles par étendue pour identifier les contrôles personnalisés qui s'appliquent au niveau de configuration actuel et ceux qui sont hérités d'un niveau parent.

Ajoutez un contrôle personnalisé lorsque vous souhaitez spécifier le mappage de préfixe/d’espace de noms d’étiquette pour un contrôle personnalisé utilisé dans plusieurs pages d’une application.

Remarque

L’ajout d’un paramètre de configuration ajoute le paramètre au niveau local et aux niveaux enfants qui héritent du paramètre.

Si vous décidez de configurer des paramètres d'application, vous avez besoin des informations suivantes pour chaque paramètre que vous voulez configurer :

  1. Spécifiez un nom pour le paramètre.
  2. Spécifiez une valeur pour le paramètre.

2.4. Paramètres de compilation .NET

Pour que le code d'application traite les demandes des utilisateurs, ASP.NET doit d'abord compiler le code dans un ou plusieurs assemblys. Les assemblys sont des fichiers qui ont une extension de nom de fichier .dll. Configurez les paramètres de compilation .NET dans IIS 8 lorsque vous souhaitez contrôler la façon dont ASP.NET code est compilé.

IIS vous permet de configurer les paramètres de compilation .NET suivants :

  • Paramètres de lot, tels que la taille de fichier maximale que vous pouvez traiter par lot et le nombre maximal de pages que vous pouvez avoir par compilation par lot.
  • Paramètres de comportement, tels que le nombre de fois où les ressources sont compilées dynamiquement avant le redémarrage de l’application.
  • Paramètres généraux, tels que le langage de programmation par défaut utilisé dans les fichiers de compilation dynamique.

2.5. Paramètres de globalisation .NET

La globalisation est le processus qui consiste à internationaliser le code d'application, puis à localiser l'application pour d'autres langues et cultures. Le processus d’internationalisation permet de traduire, stocker, récupérer et présenter du contenu d’application pour tous les paramètres régionaux à l’aide de la même base de code d’application chaque fois que possible. Les paramètres régionaux sont la combinaison de la langue et de l'environnement culturel. Cela comprend les formats de date, les heures, les devises, les numéros de téléphone, et ainsi de suite. La localisation consiste à adapter votre application à d'autres paramètres régionaux en traduisant et en mettant en forme le contenu en fonction de la culture ciblée, de préférence sans toucher au code.

Vous pouvez modifier les paramètres de globalisation des applications ASP.NET au niveau du serveur web quand vous souhaitez qu'ils s'appliquent à toutes les applications ASP.NET sur le serveur. Vous pouvez également modifier les paramètres de globalisation ASP.NET pour des sites, des applications, des répertoires et des fichiers.

IIS vous permet de configurer les paramètres de globalisation suivants :

  • Paramètres de culture, tels que la culture de l’interface utilisateur ou la langue de l’interface utilisateur.
  • Paramètres d’encodage, tels que l’encodage pour les en-têtes de réponse.

Remarque

La modification d’un paramètre de configuration modifie le paramètre au niveau local et pour tous les niveaux enfants qui héritent du paramètre.