Différences principales entre IIS et le serveur de développement ASP.NET (C#)
par Scott Mitchell
Lorsque vous testez une application ASP.NET localement, il est probable que vous utilisiez le serveur web de développement ASP.NET. Toutefois, le site web de production est probablement alimenté par IIS. Il existe des différences entre la façon dont ces serveurs web gèrent les requêtes, et ces différences peuvent avoir des conséquences importantes. Ce tutoriel explore certaines des différences les plus germaniques.
Introduction
Chaque fois qu’un utilisateur visite une application ASP.NET, son navigateur envoie une demande au site web. Cette demande est récupérée par le logiciel serveur web, qui se coordonne avec le runtime ASP.NET pour générer et retourner le contenu de la ressource demandée. LesI nternet I nformation S ervices (IIS) sont une suite de services qui fournissent des fonctionnalités Internet courantes pour les serveurs Windows. IIS est le serveur web le plus couramment utilisé pour ASP.NET applications dans les environnements de production ; il s’agit probablement du logiciel serveur web utilisé par votre fournisseur d’hôte web pour servir votre application ASP.NET. IIS peut également être utilisé comme logiciel serveur web dans l’environnement de développement, bien que cela implique d’installer IIS et de le configurer correctement.
Le serveur de développement ASP.NET est une option de serveur web alternative pour l’environnement de développement . il est fourni avec et est intégré à Visual Studio. Sauf si l’application web a été configurée pour utiliser IIS, le serveur de développement ASP.NET est automatiquement démarré et utilisé comme serveur web la première fois que vous visitez une page web à partir de Visual Studio. Les applications web de démonstration que nous avons créées dans le didacticiel Détermination des fichiers qui doivent être déployés étaient toutes deux des applications web basées sur un système de fichiers qui n’étaient pas configurées pour utiliser IIS. Par conséquent, lorsque vous visitez l’un de ces sites web à partir de Visual Studio, le serveur de développement ASP.NET est utilisé.
Dans un monde parfait, les environnements de développement et de production seraient identiques. Toutefois, comme nous l’avons vu dans le tutoriel précédent, il n’est pas rare que les environnements aient des paramètres de configuration différents. L’utilisation de différents logiciels serveur web dans les environnements ajoute une autre variable qui doit être prise en considération lors du déploiement d’une application. Ce tutoriel décrit les principales différences entre IIS et le serveur de développement ASP.NET. En raison de ces différences, il existe des scénarios où le code qui s’exécute parfaitement dans l’environnement de développement lève une exception ou se comporte différemment lorsqu’il est exécuté en production.
Différences de contexte de sécurité
Chaque fois que le logiciel serveur web gère une requête entrante, il associe cette requête à un contexte de sécurité particulier. Ces informations de contexte de sécurité sont utilisées par le système d’exploitation pour déterminer les actions autorisées par la demande. Par exemple, une page ASP.NET peut inclure du code qui journalise un message dans un fichier sur le disque. Pour que cette page ASP.NET s’exécute sans erreur, le contexte de sécurité doit disposer des autorisations appropriées au niveau du système de fichiers, à savoir les autorisations d’écriture sur ce fichier.
Le serveur de développement ASP.NET associe les requêtes entrantes au contexte de sécurité de l’utilisateur actuellement connecté. Si vous êtes connecté à votre bureau en tant qu’administrateur, les pages ASP.NET servies par le serveur de développement ASP.NET auront les mêmes droits d’accès qu’un administrateur. Toutefois, ASP.NET demandes gérées par IIS sont associées à un compte d’ordinateur spécifique. Par défaut, le compte d’ordinateur du service réseau est utilisé par IIS versions 6 et 7, bien que votre fournisseur d’hôte web ait peut-être configuré un compte unique pour chaque client. De plus, votre fournisseur d’hôte web a probablement accordé des autorisations limitées à ce compte d’ordinateur. Le résultat net est que vous pouvez avoir des pages web qui s’exécutent sans erreur dans l’environnement de développement, mais qui génèrent des exceptions liées à l’autorisation lorsqu’elles sont hébergées dans l’environnement de production.
Pour afficher ce type d’erreur en action, j’ai créé une page dans le site web Book Reviews qui crée un fichier sur le disque qui stocke la date et l’heure les plus récentes où quelqu’un a consulté la révision Apprendre vous-même ASP.NET 3.5 en 24 heures . Pour suivre la procédure, ouvrez la ~/Tech/TYASP35.aspx page et ajoutez le code suivant au gestionnaire d’événements Page_Load :
protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
Notes
La File.WriteAllText méthode crée un fichier s’il n’existe pas, puis y écrit le contenu spécifié. Si le fichier existe déjà, son contenu existant est remplacé.
Ensuite, visitez la page de révision du livre Teach Yourself ASP.NET 3.5 in 24 Hours dans l’environnement de développement à l’aide du serveur de développement ASP.NET. En supposant que vous êtes connecté à votre ordinateur avec un compte disposant des autorisations adéquates pour créer et modifier un fichier texte dans le répertoire racine de l’application web, la révision du livre apparaît comme précédemment, mais chaque fois que la page est visitée, la date et l’heure et l’adresse IP de l’utilisateur sont stockées dans le LastTYASP35Access.txt fichier. Pointez votre navigateur vers ce fichier ; Vous devriez voir un message similaire à celui présenté dans la figure 1.
Figure 1 : Le fichier texte contient la date et l’heure de la dernière visite de la révision du livre (cliquez pour afficher l’image en taille réelle)
Déployez l’application web en production, puis accédez à la page hébergée Teach Yourself ASP.NET 3.5 in 24 Hours book review. À ce stade, vous devriez voir la page de révision du livre normale ou le message d’erreur illustré dans la figure 2. Certains fournisseurs d’hôtes web accordent des autorisations d’écriture au compte d’ordinateur ASP.NET anonyme, auquel cas la page fonctionnera sans erreur. Si, toutefois, votre fournisseur d’hôte web interdit l’accès en écriture pour le compte anonyme, une UnauthorizedAccessException exception est levée lorsque la TYASP35.aspx page tente d’écrire la date et l’heure actuelles dans le LastTYASP35Access.txt fichier.
Figure 2 : Le compte d’ordinateur par défaut utilisé par IIS ne dispose pas des autorisations d’écriture dans le système de fichiers (cliquez pour afficher l’image en taille réelle)
La bonne nouvelle est que la plupart des fournisseurs d’hôtes web disposent d’une sorte d’outil d’autorisations qui vous permet de spécifier des autorisations de système de fichiers dans votre site web. Accordez au compte anonyme ASP.NET un accès en écriture au répertoire racine, puis revenez à la page de révision du livre. (Si nécessaire, contactez votre fournisseur d’hôte web pour obtenir de l’aide sur la façon d’accorder des autorisations d’écriture au compte de ASP.NET par défaut.) Cette fois, la page doit se charger sans erreur et le LastTYASP35Access.txt fichier doit être créé avec succès.
L’élément à retenir ici est que, étant donné que le serveur de développement ASP.NET fonctionne dans un contexte de sécurité différent de celui d’IIS, il est possible que vos pages ASP.NET qui lisent ou écrivent dans le système de fichiers, lisent ou écrivent dans le journal des événements Windows, ou lisent ou écrivent dans le Registre Windows fonctionnent comme prévu lors du développement, mais génèrent des exceptions en production. Lorsque vous créez une application web qui sera déployée dans un environnement d’hébergement web partagé, ne lisez pas ou n’écrivez pas dans le journal des événements ou le Registre Windows. Notez également les ASP.NET pages qui lisent ou écrivent dans le système de fichiers, car vous devrez peut-être accorder des privilèges de lecture et d’écriture sur les dossiers appropriés dans l’environnement de production.
Différences lors de la distribution de contenu statique
Une autre différence principale entre IIS et le serveur de développement ASP.NET est la façon dont ils gèrent les demandes de contenu statique. Chaque requête qui arrive dans le serveur de développement ASP.NET, que ce soit pour une page ASP.NET, une image ou un fichier JavaScript, est traitée par le runtime ASP.NET. Par défaut, IIS appelle uniquement le runtime ASP.NET lorsqu’une demande est envoyée pour une ressource ASP.NET, telle qu’une page web ASP.NET, un service Web, etc. Les demandes de contenu statique (images, fichiers CSS, fichiers JavaScript, fichiers PDF, fichiers ZIP, etc.) sont récupérées par IIS sans intervention du runtime ASP.NET. (Il est possible d’indiquer à IIS de travailler avec le runtime ASP.NET lors de la distribution de contenu statique. Pour plus d’informations, consultez la section « Exécution de l’authentification et de l’authentification d’URL Forms-Based sur les fichiers statiques avec IIS 7 ».
Le runtime ASP.NET effectue un certain nombre d’étapes pour générer le contenu demandé, notamment l’authentification (identification du demandeur) et l’autorisation (en déterminant si le demandeur a l’autorisation d’afficher le contenu demandé). Une forme d’authentification populaire est l’authentification basée sur les formulaires, dans laquelle un utilisateur est identifié en entrant ses informations d’identification (généralement un nom d’utilisateur et un mot de passe) dans les zones de texte d’une page web. Lors de la validation de ses informations d’identification, le site web stocke un cookie de ticket d’authentification sur le navigateur de l’utilisateur, qui est envoyé avec chaque demande ultérieure au site web et qui est utilisé pour authentifier l’utilisateur. En outre, il est possible de spécifier des règles d’autorisation d’URL qui dictent les utilisateurs qui peuvent ou ne peuvent pas accéder à un dossier particulier. De nombreux sites web ASP.NET utilisent l’authentification basée sur les formulaires et l’autorisation d’URL pour prendre en charge les comptes d’utilisateur et définir des parties du site qui ne sont accessibles qu’aux utilisateurs authentifiés ou aux utilisateurs appartenant à un rôle donné.
Notes
Pour un examen approfondi d’ASP. L’authentification basée sur les formulaires de NET, l’autorisation d’URL et d’autres fonctionnalités liées au compte d’utilisateur, veillez à case activée mes didacticiels sur la sécurité du site web.
Prenons l’exemple d’un site web qui prend en charge les comptes d’utilisateur à l’aide de l’autorisation basée sur les formulaires et qui a un dossier qui, à l’aide de l’autorisation d’URL, est configuré pour autoriser uniquement les utilisateurs authentifiés. Imaginez que ce dossier contient ASP.NET pages et fichiers PDF et que l’intention est que seuls les utilisateurs authentifiés puissent afficher ces fichiers PDF.
Que se passe-t-il si un visiteur tente d’afficher l’un de ces fichiers PDF en entrant l’URL directement dans la barre d’adresse de son navigateur ? Pour le savoir, nous allons créer un dossier dans le site Book Reviews, ajouter des fichiers PDF et configurer le site pour utiliser l’autorisation d’URL afin d’interdire aux utilisateurs anonymes de visiter ce dossier. Si vous téléchargez l’application de démonstration, vous verrez que j’ai créé un dossier appelé PrivateDocs et que j’ai ajouté un PDF à partir de mes didacticiels sur la sécurité du site web (comment faire !). Le PrivateDocs dossier contient également un Web.config fichier qui spécifie les règles d’autorisation d’URL pour refuser les utilisateurs anonymes :
<?xml version="1.0"?>
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Enfin, j’ai configuré l’application web pour utiliser l’authentification basée sur les formulaires en mettant à jour le Web.config fichier dans le répertoire racine, en remplaçant :
<authentication mode="Windows" />
Par :
<authentication mode="Forms" />
À l’aide du serveur de développement ASP.NET, visitez le site et entrez l’URL directe de l’un des fichiers PDF dans la barre d’adresse de votre navigateur. Si vous avez téléchargé le site web associé à ce didacticiel, l’URL doit ressembler à ceci : http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf
Si vous entrez cette URL dans la barre d’adresse, le navigateur envoie une demande au serveur de développement ASP.NET pour le fichier. Le serveur de développement ASP.NET transmet la demande au runtime ASP.NET pour traitement. Étant donné que nous ne nous sommes pas encore connectés et que le Web.config dans le PrivateDocs dossier est configuré pour refuser l’accès anonyme, le runtime ASP.NET nous redirige automatiquement vers la page Login.aspx de connexion (voir la figure 3). Lors de la redirection de l’utilisateur vers la page de connexion, ASP.NET inclut un ReturnUrl paramètre de chaîne de requête qui indique la page que l’utilisateur tentait d’afficher. Une fois la connexion établie, l’utilisateur peut être retourné à cette page.
Figure 3 : Les utilisateurs non autorisés sont automatiquement redirigés vers la page de connexion (cliquer pour afficher l’image en taille réelle)
Voyons maintenant comment cela se comporte en production. Déployez votre application et entrez l’URL directe vers l’un des fichiers PDF du PrivateDocs dossier en production. Cela invite votre navigateur à envoyer une requête IIS pour le fichier. Étant donné qu’un fichier statique est demandé, IIS récupère et retourne le fichier sans appeler le runtime ASP.NET. Par conséquent, aucune autorisation d’URL n’a été case activée effectuée ; le contenu du fichier PDF supposément privé est accessible à toute personne qui connaît l’URL directe du fichier.
Figure 4 : Les utilisateurs anonymes peuvent télécharger les fichiers PDF privés en entrant l’URL directe du fichier (cliquez pour afficher l’image en taille réelle)
Exécution de l’authentification Forms-Based et de l’authentification d’URL sur des fichiers statiques avec IIS 7
Il existe deux techniques que vous pouvez utiliser pour protéger le contenu statique contre les utilisateurs non autorisés. IIS 7 a introduit le pipeline intégré, qui associe le flux de travail d’IIS au flux de travail du runtime ASP.NET. En résumé, vous pouvez demander à IIS d’appeler le ASP.NET modules d’authentification et d’autorisation du runtime toutes les demandes entrantes (y compris le contenu statique comme les fichiers PDF). Contactez votre fournisseur d’hôte web pour savoir comment configurer votre site web pour utiliser le pipeline intégré.
Une fois qu’IIS a été configuré pour utiliser le pipeline intégré, ajoutez le balisage suivant au Web.config fichier dans le répertoire racine :
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Ce balisage indique à IIS 7 d’utiliser les modules d’authentification et d’autorisation basés sur ASP.NET. Redéployez votre application, puis visitez à nouveau le fichier PDF. Cette fois, quand IIS gère la demande, il donne au ASP.NET la logique d’authentification et d’autorisation du runtime la possibilité d’inspecter la demande. Étant donné que seuls les utilisateurs authentifiés sont autorisés à afficher le contenu du PrivateDocs dossier, le visiteur anonyme est automatiquement redirigé vers la page de connexion (reportez-vous à la figure 3).
Notes
Si votre fournisseur d’hôte web utilise toujours IIS 6, vous ne pouvez pas utiliser la fonctionnalité de pipeline intégré. Une solution de contournement consiste à placer vos documents privés dans un dossier qui interdit l’accès HTTP (par App_Dataexemple), puis à créer une page pour servir ces documents. Cette page peut être appelée GetPDF.aspx, et est passée le nom du FICHIER PDF via un paramètre de chaîne de requête. La GetPDF.aspx page vérifie d’abord que l’utilisateur est autorisé à afficher le fichier et, le cas échéant, utilise la Response.WriteFile(filePath) méthode pour renvoyer le contenu du fichier PDF demandé au client demandeur. Cette technique fonctionne également pour IIS 7 si vous ne souhaitez pas activer le pipeline intégré.
Résumé
Les applications web dans un environnement de production sont hébergées à l’aide du logiciel serveur web IIS de Microsoft. Toutefois, dans l’environnement de développement, l’application peut être hébergée à l’aide d’IIS ou du serveur de développement ASP.NET. Dans l’idéal, le même logiciel serveur web doit être utilisé dans les deux environnements, car l’utilisation de logiciels différents ajoute une autre variable dans la combinaison. Toutefois, la facilité d’utilisation du serveur de développement ASP.NET en fait un choix attrayant dans l’environnement de développement. La bonne nouvelle est qu’il n’y a que quelques différences fondamentales entre IIS et le serveur de développement ASP.NET, et si vous êtes conscient de ces différences, vous pouvez prendre des mesures pour vous assurer que l’application fonctionne et fonctionne de la même façon, quel que soit l’environnement.
Bonne programmation!
En savoir plus
Pour plus d’informations sur les sujets abordés dans ce didacticiel, consultez les ressources suivantes :