Concepts de base et prise en charge de la sécurité par ASP.NET (C#)
par Scott Mitchell
Notes
Depuis la rédaction 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 d’identité ASP.NET plutôt que les fournisseurs d’appartenance proposés au moment de la rédaction de cet article. 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 tutoriel d’une série de tutoriels qui explorent les techniques d’authentification des visiteurs via un formulaire web, l’autorisation d’accès à des pages et fonctionnalités particulières et la gestion des comptes d’utilisateur dans une application ASP.NET.
Introduction
Qu’est-ce que les forums, les sites e-commerce, les sites de messagerie en ligne, les sites web portail et les sites de réseaux sociaux ont en commun ? Ils offrent tous des comptes d’utilisateur. Les sites qui proposent des comptes d’utilisateur doivent fournir un certain nombre de services. Au minimum, les nouveaux visiteurs doivent être en mesure de créer un compte et les visiteurs de retour doivent être en mesure de se connecter. Ces applications web peuvent prendre des décisions en fonction de l’utilisateur connecté : certaines pages ou actions peuvent être limitées aux utilisateurs connectés 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 tutoriel d’une série de tutoriels qui explorent les techniques d’authentification des visiteurs via un formulaire web, l’autorisation d’accès à des pages et fonctionnalités particulières et la gestion des comptes d’utilisateur dans une application ASP.NET. Au cours de ces tutoriels, nous examinerons comment :
- Identifier et connecter les utilisateurs à un site web
- Utilisez ASP. Infrastructure 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é
- Personnaliser et étendre ASP. Contrôles web de sécurité de NET
Ces tutoriels sont conçus pour être concis et fournissent des instructions pas à pas avec de nombreuses captures d’écran pour vous guider à travers le processus visuellement. Chaque tutoriel 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 aider à implémenter l’authentification par formulaire, l’autorisation, les comptes d’utilisateur et les rôles. C’est parti !
Notes
La sécurité est un aspect important de toute application qui couvre les décisions physiques, technologiques et stratégiques et qui nécessite un haut degré de planification et de connaissance du 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 problèmes 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 tout au long de cette série de tutoriels. J’aimerais 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 qui effectue la demande. 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és 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 sait, tel qu’un mot de passe ou un code confidentiel. Les informations utilisées pour identifier un utilisateur (par exemple son nom d’utilisateur et son mot de passe) 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 où les utilisateurs se connectent au site en fournissant leurs informations d’identification dans un formulaire de page web. Nous avons tous déjà expérimenté ce type d’authentification. Accédez à n’importe quel site de commerce électronique. Lorsque vous êtes prêt à case activée, vous êtes invité à vous connecter en entrant votre nom d’utilisateur et votre mot de passe dans les zones de texte d’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 qui effectue la demande. L’autorisation est le processus qui consiste à déterminer si un utilisateur particulier a le pouvoir d’accéder à une ressource ou à une fonctionnalité spécifique.
Un compte d’utilisateur est un magasin permettant de conserver des informations sur un utilisateur particulier. Les comptes d’utilisateur doivent inclure au minimum des informations qui identifient l’utilisateur de manière unique, 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 ; la date et l’heure de la dernière connexion ; prénom et nom ; numéro de téléphone ; et adresse postale. Lors de l’utilisation de 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 en rôles. Un rôle est simplement une étiquette qui est 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 Administrateur avec des règles d’autorisation qui interdisent à quiconque, sauf à un administrateur, d’accéder à un ensemble particulier de pages web. En outre, 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 des 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 d’utilisateur 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, il envoie 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 de tout autre type de contenu. Le serveur web est chargé de retourner le contenu demandé. Ce faisant, il doit déterminer un certain nombre d’éléments concernant la demande, notamment qui a fait 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 ne disposent d’aucune information d’identification. Mais 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 qui effectue la demande. Les étapes du workflow 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 formulaire, mais prenons une minute pour comparer et comparer Authentification Windows magasins d’utilisateurs et le 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 à peu près de la même manière : lorsqu’une requête anonyme non autorisée arrive, le serveur web renvoie une réponse HTTP qui indique qu’une autorisation est nécessaire 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 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 à fournir 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 organization. C’est courant 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, supprimant ainsi la boîte de dialogue illustrée à la figure 1. Bien que Authentification Windows soit idéal pour les applications intranet, il est généralement irréalisable pour les applications Internet, car vous ne souhaitez pas créer de comptes Windows pour chaque utilisateur qui s’inscrit sur votre site.
Authentification via 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 l’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 envoyées, 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é sous la forme d’un cookie sur l’ordinateur client. Par conséquent, les visites ultérieures 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 qu’il s’est 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é (comme dans la figure 2 lorsqu’il tente de visiter anonymement ProtectedPage.aspx), le système d’autorisation signale que l’utilisateur est refusé, ce qui entraîne le système d’authentification par formulaire à rediriger automatiquement l’utilisateur vers la page de connexion.
Une fois que l’utilisateur s’est correctement connecté, les requêtes HTTP suivantes incluent le ticket d’authentification par formulaire. Le système d’authentification par formulaire identifie simplement l’utilisateur : c’est le 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 approfondir 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 Authentification ASP.NET.
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 le pouvoir d’accéder à un fichier ou à un répertoire spécifique :
- Autorisation de fichier : étant donné que ASP.NET pages et les services web sont implémentés en tant que fichiers résidant sur le système de fichiers du serveur web, l’accès à ces fichiers peut être spécifié via Access Control Listes (ACL). L’autorisation de fichier est la plus couramment utilisée avec Authentification Windows, car les listes de contrôle d’accès sont des autorisations qui s’appliquent aux comptes Windows. Lors de l’utilisation de l’authentification par formulaire, toutes les requêtes 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 l’autorisation d’URL, le développeur de page 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 à certaines pages ou répertoires de l’application ou auxquels l’accès est refusé.
L’autorisation de fichier et l’autorisation d’URL définissent des règles d’autorisation pour accéder à une page ASP.NET particulière ou à toutes les pages ASP.NET d’un répertoire particulier. À l’aide de ces techniques, nous pouvons demander à ASP.NET de refuser les demandes adressées à une page particulière pour un utilisateur particulier, ou d’autoriser l’accès à un ensemble d’utilisateurs et de refuser l’accès à tout le monde. Qu’en est-il des scénarios où tous les utilisateurs peuvent accéder à la page, mais où les fonctionnalités de la page dépendent 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 pour se connecter au site, tandis qu’un utilisateur authentifié verrait plutôt un message comme Bienvenue, Nom d’utilisateur ainsi qu’un lien pour se déconnecter. Autre exemple : lors de la consultation d’un article sur un site d’enchères, vous voyez différentes informations selon que vous êtes un enchérisseur ou celui qui l’a mis aux enchères.
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 par rapport aux 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 programmation si la demande actuelle est authentifiée, qui est l’utilisateur et à quels rôles il appartient (le cas échéant). Vous pouvez utiliser ces informations pour ensuite afficher ou masquer des colonnes dans une grille ou des panneaux de la page.
Cette série comprend trois tutoriels qui se concentrent sur l’autorisation. L’autorisation basée sur l’utilisateurexamine comment limiter l’accès à une ou plusieurs pages d’un annuaire pour des comptes d’utilisateur spécifiques ; L’autorisation basée sur les rôles examine la fourniture de règles d’autorisation au niveau du rôle ; enfin, le didacticiel Affichage du contenu basé sur l’utilisateur actuellement connecté explore la modification du contenu et des fonctionnalités d’une page particulière en fonction de la visite de la page par l’utilisateur. Pour plus d’informations sur ASP. Options d’autorisation de NET, consultez autorisation ASP.NET.
Comptes et rôles d’utilisateur
ASP. L’authentification par formulaire de NET fournit une infrastructure permettant aux utilisateurs de se connecter à un site et d’avoir leur état authentifié mémorisé lors des visites de page. 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 des fonctionnalités, 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 ont également été sur le point de concevoir les interfaces utilisateur et d’écrire le code pour les pages essentielles liées au compte d’utilisateur, comme la page de connexion et la page de création d’un nouveau 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 prendre 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 de l’espace de noms System.Web.Security qui fournissent des fonctionnalités pour 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 proprement 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 de détails d’implémentation. Au lieu de cela, les méthodes de la classe Membership appellent le fournisseur configuré, qui est celui 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 à quel fournisseur 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’appartenance dans le .NET Framework :
- ActiveDirectoryMembershipProvider : implémente l’API d’appartenance dans les serveurs Active Directory et ADAM (Active Directory Application Mode).
- SqlMembershipProvider : implémente l’API d’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 connectées en toute transparence à l’infrastructure (cliquez pour afficher l’image en taille réelle)
L’avantage du modèle de fournisseur est que d’autres implémentations peuvent être développées par Microsoft, des fournisseurs tiers ou des développeurs individuels et être connectées de manière transparente à 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’appartenance, reportez-vous à Provider Toolkit, qui comprend une procédure pas à pas des fournisseurs d’appartenance, 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 au-dessus du modèle de 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 du 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 SEULE API orientée vers l’avant (les 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 page. Cette API unifiée permet à Microsoft et aux fournisseurs tiers de créer des contrôles web qui s’interfacent avec les frameworks Appartenance et Rôles. ASP.NET est fourni avec un certain nombre de contrôles Web de connexion pour l’implémentation d’interfaces utilisateur de compte d’utilisateur courantes. Par exemple, le contrôle De connexion invite un utilisateur à fournir ses informations d’identification, les valide, puis les enregistre via l’authentification par formulaire. Le contrôle LoginView offre des modèles pour afficher des balises différentes pour les utilisateurs anonymes et les utilisateurs authentifiés, ou un balisage différent 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.
Sous le couvre les différents contrôles de connexion interagissent avec les frameworks Appartenance et 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 prochains tutoriels, y compris 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 connexion status mémorisées lors des visites de page, une page web permettant aux nouveaux visiteurs de créer un compte et la possibilité pour le développeur de pages de spécifier quelle ressource, les données et les fonctionnalités sont disponibles pour quels utilisateurs ou rôles. Les tâches d’authentification et d’autorisation des utilisateurs et de gestion des comptes et rôles d’utilisateur sont remarquablement faciles à accomplir dans ASP.NET applications grâce à l’authentification par formulaire, à l’autorisation d’URL et aux frameworks Appartenance et Rôles.
Au cours des prochains tutoriels, nous examinerons ces aspects en créant une application web de travail à partir de la base, pas à pas. Dans les deux prochains tutoriels, nous allons explorer l’authentification par formulaire en détail. Nous verrons le flux de travail d’authentification par formulaire en action, décortiquer 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 !
En savoir plus
Pour plus d’informations sur les sujets abordés dans ce tutoriel, reportez-vous aux ressources suivantes :
- ASP.NET 2.0 Appartenance, rôles, authentification par formulaire et ressources de sécurité
- Instructions de sécurité ASP.NET 2.0
- Authentification ASP.NET
- autorisation 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 Sécurité sur le site MSDN
- Professional ASP.NET 2.0 Security, Membership, and Role Management (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 comme consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 in 24 Heures. Il est accessible à l’adressemitchell@4GuysFromRolla.com . ou via son blog, qui peut être trouvé à l’adresse http://ScottOnWriting.NET.
Un merci spécial à
Cette série de tutoriels a été examinée par de nombreux réviseurs utiles. Réviseur principal de ce tutoriel a été examiné par de nombreux réviseurs utiles. Parmi les réviseurs principaux de ce tutoriel figurent 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.