Concepts de base et prise en charge de la sécurité par ASP.NET (C#)
par Scott Mitchell
Remarque
Depuis l’écriture de cet article, les fournisseurs d’appartenance ASP.NET ont été remplacés par ASP.NET Identity. Nous vous recommandons vivement de mettre à jour les applications pour utiliser la plateforme ASP.NET Identity plutôt que les fournisseurs d’appartenance proposés au moment où cet article a été écrit. ASP.NET Identity présente un certain nombre d’avantages par rapport au système d’appartenance ASP.NET, notamment :
- Meilleures performances
- Extensibilité et testabilité améliorées
- Prise en charge d’OAuth, OpenID Connect et de l’authentification à deux facteurs
- Prise en charge des identités basées sur les revendications
- Meilleure interopérabilité avec ASP.Net Core
Il s’agit du premier didacticiel d’une série de didacticiels qui exploreront les techniques d’authentification des visiteurs via un formulaire web, en autorisant l’accès à des pages et fonctionnalités particulières et en gérant les comptes d’utilisateur dans une application ASP.NET.
Introduction
Quels sont les forums, sites e Commerce électronique, sites de messagerie en ligne, sites web portail et sites de réseau social ont tous en commun ? Ils offrent tous des comptes d’utilisateur. Les sites qui offrent des comptes d’utilisateur doivent fournir un certain nombre de services. Au minimum, les nouveaux visiteurs doivent pouvoir créer un compte et retourner des visiteurs doivent pouvoir se connecter. Ces applications web peuvent prendre des décisions basées sur l’utilisateur connecté : certaines pages ou actions peuvent être limitées aux utilisateurs connectés uniquement ou à un certain sous-ensemble d’utilisateurs ; D’autres pages peuvent afficher des informations spécifiques à l’utilisateur connecté, ou afficher plus ou moins d’informations, selon l’utilisateur qui consulte la page.
Il s’agit du premier didacticiel d’une série de didacticiels qui exploreront les techniques d’authentification des visiteurs via un formulaire web, en autorisant l’accès à des pages et fonctionnalités particulières et en gérant les comptes d’utilisateur dans une application ASP.NET. Au cours de ces tutoriels, nous allons examiner comment :
- Identifier et connecter des utilisateurs à un site web
- Utilisez ASP. Framework d’appartenance de NET pour gérer les comptes d’utilisateur
- Créer, mettre à jour et supprimer des comptes d’utilisateur
- Limiter l’accès à une page web, à un répertoire ou à des fonctionnalités spécifiques en fonction de l’utilisateur connecté
- Utilisez ASP. Infrastructure de rôles de NET pour associer des comptes d’utilisateur à des rôles
- Gérer les rôles d’utilisateur
- Limiter l’accès à une page web, à un répertoire ou à des fonctionnalités spécifiques en fonction du rôle de l’utilisateur connecté
- Personnalisez et étendez ASP. Contrôles web de sécurité de NET
Ces didacticiels sont destinés à être concis et fournissent des instructions pas à pas avec de nombreuses captures d’écran pour vous guider visuellement dans le processus. Chaque didacticiel est disponible dans les versions C# et Visual Basic et inclut un téléchargement du code complet utilisé. (Ce premier tutoriel se concentre sur les concepts de sécurité d’un point de vue général et ne contient donc pas de code associé.)
Dans ce tutoriel, nous aborderons les concepts de sécurité importants et les fonctionnalités disponibles dans ASP.NET pour faciliter l’implémentation de l’authentification, de l’autorisation, des comptes d’utilisateur et des rôles de formulaires. C’est parti !
Remarque
La sécurité est un aspect important de toute application qui s’étend sur les décisions physiques, technologiques et stratégiques et nécessite un niveau élevé de planification et de connaissances sur le domaine. Cette série de tutoriels n’est pas destinée à servir de guide pour le développement d’applications web sécurisées. Au lieu de cela, il se concentre spécifiquement sur l’authentification par formulaire, l’autorisation, les comptes d’utilisateur et les rôles. Bien que certains concepts de sécurité autour de ces questions soient abordés dans cette série, d’autres sont laissés inexplorés.
Authentification, autorisation, comptes d’utilisateur et rôles
L’authentification, l’autorisation, les comptes d’utilisateur et les rôles sont quatre termes qui seront utilisés très souvent dans cette série de tutoriels. Je voudrais donc prendre un moment rapide pour définir ces termes dans le contexte de la sécurité web. Dans un modèle client-serveur, tel qu’Internet, il existe de nombreux scénarios dans lesquels le serveur doit identifier le client effectuant la requête. L’authentification est le processus de vérification de l’identité du client. Un client qui a été identifié avec succès est dit authentifié. Un client non identifié est dit non authentifié ou anonyme.
Les systèmes d’authentification sécurisé impliquent au moins l’une des trois facettes suivantes : quelque chose que vous connaissez, quelque chose que vous avez ou quelque chose que vous êtes. La plupart des applications web s’appuient sur quelque chose que le client connaît, comme un mot de passe ou un code confidentiel. Les informations utilisées pour identifier un utilisateur ( son nom d’utilisateur et son mot de passe, par exemple) sont appelées informations d’identification. Cette série de tutoriels se concentre sur l’authentification par formulaire, qui est un modèle d’authentification dans lequel les utilisateurs se connectent au site en fournissant leurs informations d’identification dans un formulaire de page web. Nous avons tous déjà connu ce type d’authentification. Accédez à n’importe quel site eCommerce. Lorsque vous êtes prêt à vérifier que vous êtes invité à vous connecter en entrant votre nom d’utilisateur et votre mot de passe dans des zones de texte sur une page web.
En plus d’identifier les clients, un serveur peut avoir besoin de limiter les ressources ou fonctionnalités accessibles en fonction du client effectuant la requête. L’autorisation est le processus permettant de déterminer si un utilisateur particulier a l’autorité d’accéder à une ressource ou à une fonctionnalité spécifique.
Un compte d’utilisateur est un magasin pour conserver des informations sur un utilisateur particulier. Les comptes d’utilisateur doivent inclure au minimum des informations qui identifient de manière unique l’utilisateur, telles que le nom de connexion et le mot de passe de l’utilisateur. En plus de ces informations essentielles, les comptes d’utilisateur peuvent inclure des éléments tels que : l’adresse e-mail de l’utilisateur ; date et heure de création du compte ; date et heure auxquelles ils se connectent pour la dernière fois ; prénom et nom ; numéro de téléphone; et adresse postale. Lorsque vous utilisez l’authentification par formulaire, les informations de compte d’utilisateur sont généralement stockées dans une base de données relationnelle comme Microsoft SQL Server.
Les applications web qui prennent en charge les comptes d’utilisateur peuvent éventuellement regrouper des utilisateurs dans des rôles. Un rôle est simplement une étiquette appliquée à un utilisateur et fournit une abstraction pour définir des règles d’autorisation et des fonctionnalités au niveau de la page. Par exemple, un site web peut inclure un rôle d’administrateur avec des règles d’autorisation qui interdisent à tout le monde, mais à un administrateur d’accéder à un ensemble particulier de pages web. De plus, une variété de pages accessibles à tous les utilisateurs (y compris les non-administrateurs) peut afficher des données supplémentaires ou offrir des fonctionnalités supplémentaires lorsqu’ils sont visités par les utilisateurs dans le rôle Administrateurs. À l’aide de rôles, nous pouvons définir ces règles d’autorisation sur une base de rôle par rôle plutôt que par utilisateur.
Authentification des utilisateurs dans une application ASP.NET
Lorsqu’un utilisateur entre une URL dans la fenêtre d’adresse de son navigateur ou clique sur un lien, le navigateur effectue une requête HTTP (Hypertext Transfer Protocol) au serveur web pour le contenu spécifié, qu’il s’agit d’une page ASP.NET, d’une image, d’un fichier JavaScript ou d’un autre type de contenu. Le serveur web est chargé de renvoyer le contenu demandé. Dans ce cas, il doit déterminer un certain nombre d’éléments concernant la demande, notamment qui a effectué la demande et si l’identité est autorisée à récupérer le contenu demandé.
Par défaut, les navigateurs envoient des requêtes HTTP qui n’ont pas de type d’informations d’identification. Toutefois, si le navigateur inclut des informations d’authentification, le serveur web démarre le flux de travail d’authentification, qui tente d’identifier le client effectuant la requête. Les étapes du flux de travail d’authentification dépendent du type d’authentification utilisé par l’application web. ASP.NET prend en charge trois types d’authentification : Windows, Passport et formulaires. Cette série de tutoriels se concentre sur l’authentification par formulaires, mais nous allons prendre une minute pour comparer et comparer Authentification Windows magasins d’utilisateurs et flux de travail.
Authentification via l’authentification Windows
Le flux de travail Authentification Windows utilise l’une des techniques d’authentification suivantes :
- Authentification de base
- Authentification Digest
- Authentification Windows intégrée
Les trois techniques fonctionnent de la même façon : lorsqu’une demande anonyme non autorisée arrive, le serveur web renvoie une réponse HTTP qui indique que l’autorisation est requise pour continuer. Le navigateur affiche ensuite une boîte de dialogue modale qui invite l’utilisateur à entrer son nom d’utilisateur et son mot de passe (voir la figure 1). Ces informations sont ensuite renvoyées au serveur web via un en-tête HTTP.
Figure 1 : Une boîte de dialogue modale invite l’utilisateur à entrer ses informations d’identification
Les informations d’identification fournies sont validées par rapport au Windows User Store du serveur web. Cela signifie que chaque utilisateur authentifié dans votre application web doit avoir un compte Windows dans votre organisation. Il s’agit d’une situation courante dans les scénarios intranet. En fait, lors de l’utilisation de l’authentification intégrée Windows dans un paramètre intranet, le navigateur fournit automatiquement au serveur web les informations d’identification utilisées pour se connecter au réseau, ce qui supprime la boîte de dialogue indiquée dans la figure 1. Bien que Authentification Windows soit idéal pour les applications intranet, il est généralement irrécible pour les applications Internet, car vous ne souhaitez pas créer de comptes Windows pour chaque utilisateur qui s’inscrit sur votre site.
Authentification par le biais de l’authentification par formulaire
L’authentification par formulaire, en revanche, est idéale pour les applications web Internet. Rappelez-vous que l’authentification par formulaire identifie l’utilisateur en lui invitant à entrer ses informations d’identification via un formulaire web. Par conséquent, lorsqu’un utilisateur tente d’accéder à une ressource non autorisée, il est automatiquement redirigé vers la page de connexion où il peut entrer ses informations d’identification. Les informations d’identification envoyées sont ensuite validées par rapport à un magasin d’utilisateurs personnalisé , généralement une base de données.
Après avoir vérifié les informations d’identification soumises, un ticket d’authentification par formulaire est créé pour l’utilisateur. Ce ticket indique que l’utilisateur a été authentifié et inclut des informations d’identification, telles que le nom d’utilisateur. Le ticket d’authentification par formulaire est (généralement) stocké en tant que cookie sur l’ordinateur client. Par conséquent, les visites suivantes sur le site web incluent le ticket d’authentification par formulaire dans la requête HTTP, ce qui permet à l’application web d’identifier l’utilisateur une fois connecté.
La figure 2 illustre le flux de travail d’authentification par formulaire à partir d’un point de vue général. Notez comment les éléments d’authentification et d’autorisation dans ASP.NET agir comme deux entités distinctes. Le système d’authentification par formulaire identifie l’utilisateur (ou signale qu’il est anonyme). Le système d’autorisation détermine si l’utilisateur a accès à la ressource demandée. Si l’utilisateur n’est pas autorisé (tel qu’il se trouve dans la figure 2 lorsque vous tentez de visiter anonymement ProtectedPage.aspx), le système d’autorisation signale que l’utilisateur est refusé, ce qui entraîne la redirection automatique du système d’authentification par formulaire vers la page de connexion.
Une fois l’utilisateur connecté, les requêtes HTTP suivantes incluent le ticket d’authentification par formulaire. Le système d’authentification par formulaire identifie simplement l’utilisateur : il s’agit du système d’autorisation qui détermine si l’utilisateur peut accéder à la ressource demandée.
Figure 2 : Flux de travail d’authentification par formulaire
Nous allons explorer plus en détail l’authentification par formulaire dans le tutoriel suivant, Vue d’ensemble de l’authentification par formulaire. Pour plus d’informations sur ASP. Options d’authentification de NET, consultez ASP.NET Authentification.
Limitation de l’accès aux pages web, aux répertoires et aux fonctionnalités de page
ASP.NET comprend deux façons de déterminer si un utilisateur particulier a l’autorité d’accéder à un fichier ou répertoire spécifique :
- Autorisation de fichier : étant donné que ASP.NET pages et services web sont implémentés en tant que fichiers qui résident sur le système de fichiers du serveur web, l’accès à ces fichiers peut être spécifié via des listes de contrôle d’accès (ACL). L’autorisation de fichier est généralement utilisée avec Authentification Windows, car les listes de contrôle d’accès sont des autorisations qui s’appliquent aux comptes Windows. Lorsque vous utilisez l’authentification par formulaire, toutes les demandes au niveau du système d’exploitation et du système de fichiers sont exécutées par le même compte Windows, quel que soit l’utilisateur qui visite le site.
- Autorisation d’URL : avec autorisation d’URL, le développeur de pages spécifie les règles d’autorisation dans Web.config. Ces règles d’autorisation spécifient quels utilisateurs ou rôles sont autorisés à accéder ou sont refusés d’accéder à certaines pages ou répertoires de l’application.
L’autorisation de fichier et l’autorisation d’URL définissent des règles d’autorisation pour accéder à une page de ASP.NET particulière ou pour toutes les pages ASP.NET dans un répertoire particulier. À l’aide de ces techniques, nous pouvons demander ASP.NET de refuser des demandes à une page particulière pour un utilisateur particulier, ou d’autoriser l’accès à un ensemble d’utilisateurs et de refuser l’accès à tous les autres utilisateurs. Qu’en est-il des scénarios où tous les utilisateurs peuvent accéder à la page, mais la fonctionnalité de la page dépend de l’utilisateur ? Par exemple, de nombreux sites qui prennent en charge les comptes d’utilisateur ont des pages qui affichent du contenu ou des données différents pour les utilisateurs authentifiés et les utilisateurs anonymes. Un utilisateur anonyme peut voir un lien permettant de se connecter au site, tandis qu’un utilisateur authentifié voit plutôt un message tel que Bienvenue, Nom d’utilisateur , ainsi qu’un lien pour se déconnecter. Autre exemple : lors de l’affichage d’un article sur un site d’enchères, vous voyez des informations différentes selon que vous êtes un soumissionnaire ou l’un des enchères de l’article.
Ces ajustements au niveau de la page peuvent être effectués de manière déclarative ou programmatique. Pour afficher un contenu différent pour les utilisateurs anonymes que les utilisateurs authentifiés, faites simplement glisser un contrôle LoginView sur votre page et entrez le contenu approprié dans ses modèles AnonymousTemplate et LoggedInTemplate. Vous pouvez également déterminer par programme si la requête actuelle est authentifiée, qui est l’utilisateur et quels rôles ils appartiennent (le cas échéant). Vous pouvez utiliser ces informations pour afficher ou masquer des colonnes dans une grille ou des panneaux de la page.
Cette série comprend trois didacticiels qui se concentrent sur l’autorisation. L’autorisationbasée sur l’utilisateur examine comment limiter l’accès à une page ou à des pages d’un annuaire pour des comptes d’utilisateur spécifiques ; L’autorisation basée sur les rôles examine l’approvisionnement des règles d’autorisation au niveau du rôle ; enfin, le didacticiel Affichage du contenu basé sur le didacticiel Utilisateur actuellement connecté explore la modification du contenu et des fonctionnalités d’une page particulière en fonction de l’utilisateur qui visite la page. Pour plus d’informations sur ASP. Options d’autorisation de NET, consultez ASP.NET Autorisation.
Comptes d’utilisateur et rôles
ASPIC. L’authentification par formulaires de NET fournit une infrastructure permettant aux utilisateurs de se connecter à un site et d’avoir leur état authentifié mémorisé dans les visites de pages. Et l’autorisation d’URL offre une infrastructure permettant de limiter l’accès à des fichiers ou dossiers spécifiques dans une application ASP.NET. Aucune fonctionnalité, toutefois, ne fournit un moyen de stocker les informations de compte d’utilisateur ou de gérer les rôles.
Avant ASP.NET 2.0, les développeurs étaient responsables de la création de leurs propres magasins d’utilisateurs et de rôles. Ils étaient également sur le hook pour concevoir les interfaces utilisateur et écrire le code pour les pages essentielles liées au compte d’utilisateur, comme la page de connexion et la page pour créer un compte, entre autres. Sans infrastructure de compte d’utilisateur intégrée dans ASP.NET, chaque développeur implémentant des comptes d’utilisateur devait arriver à ses propres décisions de conception sur des questions telles que, Comment faire stocker des mots de passe ou d’autres informations sensibles ? Et quelles instructions dois-je imposer en ce qui concerne la longueur et la force du mot de passe ?
Aujourd’hui, l’implémentation de comptes d’utilisateur dans une application ASP.NET est beaucoup plus simple grâce à l’infrastructure d’appartenance et aux contrôles Web de connexion intégrés. L’infrastructure d’appartenance est une poignée de classes dans l’espace de noms System.Web.Security qui fournissent des fonctionnalités permettant d’effectuer des tâches essentielles liées aux comptes d’utilisateur. La classe clé dans l’infrastructure d’appartenance est la classe Membership, qui a des méthodes telles que :
- CreateUser
- DeleteUser
- GetAllUsers
- GetUser
- UpdateUser
- ValidateUser
L’infrastructure d’appartenance utilise le modèle de fournisseur, qui sépare correctement l’API de l’infrastructure d’appartenance de son implémentation. Cela permet aux développeurs d’utiliser une API commune, mais leur permet d’utiliser une implémentation qui répond aux besoins personnalisés de leur application. En bref, la classe Membership définit les fonctionnalités essentielles de l’infrastructure (méthodes, propriétés et événements), mais ne fournit pas réellement de détails d’implémentation. Au lieu de cela, les méthodes de la classe Membership appellent le fournisseur configuré, qui est ce qui effectue le travail réel. Par exemple, lorsque la méthode CreateUser de la classe Membership est appelée, la classe Membership ne connaît pas les détails du magasin d’utilisateurs. Il ne sait pas si les utilisateurs sont gérés dans une base de données ou dans un fichier XML ou dans un autre magasin. La classe Membership examine la configuration de l’application web pour déterminer le fournisseur auquel déléguer l’appel, et cette classe de fournisseur est responsable de la création du nouveau compte d’utilisateur dans le magasin d’utilisateurs approprié. Cette interaction est illustrée dans la figure 3.
Microsoft fournit deux classes de fournisseur d’appartenances dans le .NET Framework :
- ActiveDirectoryMembershipProvider : implémente l’API Appartenance dans les serveurs Active Directory et Active Directory Application Mode (ADAM).
- SqlMembershipProvider : implémente l’API Appartenance dans une base de données SQL Server.
Cette série de tutoriels se concentre exclusivement sur SqlMembershipProvider.
Figure 03 : Le modèle de fournisseur permet à différentes implémentations d’être branchées en toute transparence dans l’infrastructure (cliquez pour afficher l’image de taille complète)
L’avantage du modèle fournisseur est que d’autres implémentations peuvent être développées par Microsoft, des fournisseurs tiers ou des développeurs individuels et connectés en toute transparence à l’infrastructure d’appartenance. Par exemple, Microsoft a publié un fournisseur d’appartenance pour les bases de données Microsoft Access. Pour plus d’informations sur les fournisseurs d’appartenances, reportez-vous au kit de ressources fournisseur, qui comprend une procédure pas à pas des fournisseurs d’appartenances, des exemples de fournisseurs personnalisés, plus de 100 pages de documentation sur le modèle de fournisseur et le code source complet pour les fournisseurs d’appartenance intégrés (à savoir, ActiveDirectoryMembershipProvider et SqlMembershipProvider).
ASP.NET 2.0 a également introduit l’infrastructure rôles. Comme l’infrastructure d’appartenance, l’infrastructure Rôles est créée en haut du modèle fournisseur. Son API est exposée via la classe Roles et le .NET Framework est fourni avec trois classes de fournisseur :
- AuthorizationStoreRoleProvider : gère les informations de rôle dans un magasin de stratégies de gestionnaire d’autorisations, tel qu’Active Directory ou ADAM.
- SqlRoleProvider : implémente des rôles dans une base de données SQL Server.
- WindowsTokenRoleProvider : associe les informations de rôle en fonction du groupe Windows du visiteur. Cette méthode est généralement utilisée avec Authentification Windows.
Cette série de tutoriels se concentre exclusivement sur SqlRoleProvider.
Étant donné que le modèle de fournisseur inclut une API orientée vers l’avant unique (classes Appartenance et rôles), il est possible de créer des fonctionnalités autour de cette API sans avoir à vous soucier des détails de l’implémentation , ceux-ci sont gérés par les fournisseurs sélectionnés par le développeur de pages. Cette API unifiée permet aux fournisseurs Microsoft et tiers de créer des contrôles Web qui s’interfacent avec les infrastructures d’appartenance et de rôles. ASP.NET fourni avec un certain nombre de contrôles Web de connexion pour implémenter des interfaces utilisateur de compte d’utilisateur courantes. Par exemple, le contrôle de connexion invite un utilisateur à entrer ses informations d’identification, à les valider, puis à les journaliser via l’authentification par formulaire. Le contrôle LoginView offre des modèles permettant d’afficher des marques différentes aux utilisateurs anonymes par rapport aux utilisateurs authentifiés ou à des marques différentes en fonction du rôle de l’utilisateur. Et le contrôle CreateUserWizard fournit une interface utilisateur pas à pas pour créer un compte d’utilisateur.
En dessous des différents contrôles de connexion interagissent avec les frameworks d’appartenance et de rôles. La plupart des contrôles de connexion peuvent être implémentés sans avoir à écrire une seule ligne de code. Nous examinerons ces contrôles plus en détail dans les didacticiels futurs, notamment les techniques d’extension et de personnalisation de leurs fonctionnalités.
Résumé
Toutes les applications web qui prennent en charge les comptes d’utilisateur nécessitent des fonctionnalités similaires, telles que la possibilité pour les utilisateurs de se connecter et d’avoir leur état de connexion mémorisé dans les visites de pages ; page web permettant aux nouveaux visiteurs de créer un compte ; et la possibilité pour le développeur de pages de spécifier la ressource, les données et les fonctionnalités disponibles pour les utilisateurs ou les rôles. Les tâches d’authentification et d’autorisation des utilisateurs et de la gestion des comptes d’utilisateur et des rôles sont remarquablement faciles à accomplir dans ASP.NET applications grâce à l’authentification par formulaire, à l’autorisation d’URL et aux infrastructures d’appartenance et de rôles.
Au cours des prochains tutoriels, nous allons examiner ces aspects en créant une application web de travail à partir de la base dans une mode pas à pas. Dans le tutoriel suivant, nous allons explorer en détail l’authentification par formulaire. Nous allons voir le flux de travail d’authentification par formulaire en action, dissecter le ticket d’authentification par formulaire, discuter des problèmes de sécurité et voir comment configurer le système d’authentification par formulaire , tout en créant une application web qui permet aux visiteurs de se connecter et de se déconnecter.
Bonne programmation !
Pour aller plus loin
Pour plus d’informations sur les sujets abordés dans ce tutoriel, consultez les ressources suivantes :
- ASP.NET 2.0 appartenances, rôles, authentification par formulaire et ressources de sécurité
- instructions de sécurité ASP.NET 2.0
- Authentification ASP.NET
- autorisation de ASP.NET
- Vue d’ensemble des contrôles de connexion ASP.NET
- Examen de l’appartenance, des rôles et du profil de ASP.NET 2.0
- Comment sécuriser mon site à l’aide de l’appartenance et des rôles ? (Vidéo)
- Présentation de l’appartenance
- Centre de développement MSDN Security
- Professionnel ASP.NET 2.0 Sécurité, Appartenance et Gestion des rôles (ISBN : 978-0-7645-9698-8)
- Kit de ressources du fournisseur
À propos de l’auteur
Scott Mitchell, auteur de sept livres ASP/ASP.NET et fondateur de 4GuysFromRolla.com, travaille avec les technologies Web Microsoft depuis 1998. Scott travaille en tant que consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 en 24 heures. Il peut être accessible à mitchell@4GuysFromRolla.com. ou via son blog, qui peut être trouvé à http://ScottOnWriting.NET.
Merci spécial à
Cette série de tutoriels a été examinée par de nombreux réviseurs utiles. Le réviseur principal de ce didacticiel a été examiné par de nombreux réviseurs utiles. Les réviseurs principaux de ce tutoriel incluent Alicja Maziarz, John Suru et Teresa Murphy. Vous souhaitez consulter mes prochains articles MSDN ? Si c’est le cas, déposez-moi une ligne à mitchell@4GuysFromRolla.com.