Configuration d’un site web qui utilise les services d’application (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

ASP.NET version 2.0 a introduit une série de services d’application, qui font partie du .NET Framework et servent de suite de services de blocs de construction que vous pouvez utiliser pour ajouter des fonctionnalités enrichies à votre application web. Ce tutoriel explique comment configurer un site web dans l’environnement de production pour utiliser les services d’application et résout les problèmes courants liés à la gestion des comptes d’utilisateur et des rôles sur l’environnement de production.

Introduction

ASP.NET version 2.0 a introduit une série de services d’application, qui font partie du .NET Framework et servent de suite de services de blocs de construction que vous pouvez utiliser pour ajouter des fonctionnalités enrichies à votre application web. Les services d’application sont les suivants :

• Appartenance : API permettant de créer et de gérer des comptes d’utilisateur.
• Rôles : API permettant de catégoriser les utilisateurs en groupes.
• Profil : UNE API permettant de stocker du contenu personnalisé et spécifique à l’utilisateur.
• Plan de site : API permettant de définir une structure logique d’un site sous la forme d’une hiérarchie, qui peut ensuite être affichée via des contrôles de navigation, tels que des menus et des navigations.
• Personnalisation : API pour la gestion des préférences de personnalisation, le plus souvent utilisée avec webParts.
• Analyse de l’intégrité : API pour surveiller les performances, la sécurité, les erreurs et d’autres métriques d’intégrité du système pour une application web en cours d’exécution.

Les API des services d’application ne sont pas liées à une implémentation spécifique. Au lieu de cela, vous demandez aux services d’application d’utiliser un fournisseur particulier, et ce fournisseur implémente le service à l’aide d’une technologie particulière. Les fournisseurs les plus couramment utilisés pour les applications web basées sur Internet hébergées dans une société d’hébergement web sont les fournisseurs qui utilisent une implémentation de base de données SQL Server. Par exemple, est SqlMembershipProvider un fournisseur pour l’API Appartenance qui stocke les informations de compte d’utilisateur dans une base de données Microsoft SQL Server.

L’utilisation des services d’application et des fournisseurs de SQL Server ajoute des difficultés lors du déploiement de l’application. Pour commencer, les objets de base de données des services d’application doivent être correctement créés sur les bases de données de développement et de production et initialisés de manière appropriée. Il existe également des paramètres de configuration importants qui doivent être définis.

Notes

Les API des services d’application ont été conçues à l’aide du modèle de fournisseur, un modèle de conception qui permet de fournir les détails d’implémentation d’une API au moment de l’exécution. Le .NET Framework est fourni avec un certain nombre de fournisseurs de services d’application qui peuvent être utilisés, tels que et SqlMembershipProviderSqlRoleProvider, qui sont des fournisseurs pour les API Appartenance et Rôles qui utilisent une implémentation de base de données SQL Server. Vous pouvez également créer et plug-in un fournisseur personnalisé. En fait, l’application web Book Reviews contient déjà un fournisseur personnalisé pour l’API Site Map (ReviewSiteMapProvider), qui construit le plan de site à partir des données des Genres tables et de Books la base de données.

Ce tutoriel commence par voir comment j’ai étendu l’application web Book Reviews pour utiliser les API Appartenance et Rôles. Il décrit ensuite le déploiement d’une application web qui utilise des services d’application avec une implémentation de base de données SQL Server et conclut en abordant les problèmes courants liés à la gestion des comptes d’utilisateur et des rôles sur l’environnement de production.

Mises à jour à l’application Book Reviews

Au cours des deux derniers tutoriels, l’application web Book Reviews a été mise à jour d’un site web statique vers une application web dynamique, pilotée par les données, avec un ensemble de pages d’administration pour la gestion des genres et des révisions. Toutefois, cette section d’administration n’est actuellement pas protégée : tout utilisateur qui connaît (ou suppose) l’URL de la page d’administration peut valser et créer, modifier ou supprimer des avis sur notre site. Un moyen courant de protéger certaines parties d’un site web consiste à implémenter des comptes d’utilisateur, puis à utiliser des règles d’autorisation d’URL pour restreindre l’accès à certains utilisateurs ou rôles. L’application web Book Reviews disponible en téléchargement avec ce tutoriel prend en charge les comptes d’utilisateur et les rôles. Il a un rôle unique défini nommé Administration et seuls les utilisateurs de ce rôle peuvent accéder aux pages d’administration.

Notes

J’ai créé trois comptes d’utilisateur dans l’application web Book Reviews : Scott, Jisun et Alice. Les trois utilisateurs ont le même mot de passe : mot de passe ! Scott et Jisun sont dans le rôle Administration, Alice ne l’est pas. Les pages de non-administration du site sont toujours accessibles aux utilisateurs anonymes. Autrement dit, vous n’avez pas besoin de vous connecter pour visiter le site, sauf si vous souhaitez l’administrer, auquel cas vous devez vous connecter en tant qu’utilisateur dans le rôle Administration.

La page de master de l’application Book Reviews a été mise à jour pour inclure une autre interface utilisateur pour les utilisateurs authentifiés et anonymes. Si un utilisateur anonyme visite le site, un lien de connexion apparaît dans le coin supérieur droit. Un utilisateur authentifié voit le message « Bienvenue, nom d’utilisateur ! » et un lien pour se déconnecter. Il existe également une page de connexion (~/Login.aspx), qui contient un contrôle Web de connexion qui fournit l’interface utilisateur et la logique pour l’authentification d’un visiteur. Seuls les administrateurs peuvent créer de nouveaux comptes. (Il existe des pages pour créer et gérer des comptes d’utilisateur dans le ~/Admin dossier.)

Configuration des API Appartenance et Rôles

L’application web Book Reviews utilise les API Appartenance et Rôles pour prendre en charge les comptes d’utilisateur et les regrouper en rôles (à savoir, le rôle Administration). Les SqlMembershipProvider classes de fournisseur et SqlRoleProvider sont utilisées parce que nous voulons stocker les informations de compte et de rôle dans une base de données SQL Server.

Notes

Ce tutoriel n’est pas destiné à être un examen détaillé de la configuration d’une application web pour prendre en charge les API Appartenance et Rôles. Pour un examen approfondi de ces API et des étapes à suivre pour configurer un site web afin de les utiliser, consultez mes tutoriels sur la sécurité des sites web.

Pour utiliser les services d’application avec une base de données SQL Server, vous devez d’abord ajouter les objets de base de données utilisés par ces fournisseurs à la base de données dans laquelle vous souhaitez stocker les informations de compte d’utilisateur et de rôle. Ces objets de base de données requis incluent une variété de tables, de vues et de procédures stockées. Sauf indication contraire, les SqlMembershipProvider classes de fournisseur et SqlRoleProvider utilisent une base de données SQL Server Express Edition nommée ASPNETDB située dans le dossier s de l’application ; si une telle base de données n’existe App_Data pas, elle est automatiquement créée avec les objets de base de données nécessaires par ces fournisseurs au moment de l’exécution.

Il est possible, et généralement idéal, de créer les objets de base de données application services dans la même base de données où sont stockées les données spécifiques de l’application du site web. Le .NET Framework est fourni avec un outil nommé aspnet_regsql.exe qui installe les objets de base de données sur une base de données spécifiée. J’ai utilisé cet outil pour ajouter ces objets à la Reviews.mdf base de données dans le App_Data dossier (la base de données de développement). Nous verrons comment utiliser cet outil plus loin dans ce tutoriel lorsque nous ajouterons ces objets à la base de données de production.

Si vous ajoutez les objets de base de données des services d’application à une base de données autre que celle-ci ASPNETDB , vous devez personnaliser les SqlMembershipProvider configurations des classes de fournisseur et SqlRoleProvider afin qu’elles utilisent la base de données appropriée. Pour personnaliser le fournisseur d’appartenance, ajoutez un <élément d’appartenance> dans la <system.web> section dans Web.config; utilisez l’élément <roleManager> pour configurer le fournisseur Roles. L’extrait de code suivant est extrait de l’application Web.config Book Reviews et montre les paramètres de configuration des API Appartenance et Rôles. Notez que les deux inscrivent un nouveau fournisseur - ReviewMembership et ReviewRole - qui utilisent les SqlMembershipProvider fournisseurs et SqlRoleProvider , respectivement.

<configuration>
    <system.web>
        ...

        <membership defaultProvider="ReviewMembership">
            <providers>
                <clear />

                <add type="System.Web.Security.SqlMembershipProvider" 
                     name="ReviewMembership" 
                     connectionStringName="ReviewsConnectionString" 
                     applicationName="BookReviews" />
            </providers>
        </membership>

        <roleManager enabled="true" defaultProvider="ReviewRole">
            <providers>
                <clear />

                <add type="System.Web.Security.SqlRoleProvider" 
                     name="ReviewRole" 
                     connectionStringName="ReviewsConnectionString" 
                     applicationName="BookReviews" />
            </providers>
        </roleManager>

        ...
    </system.web>
</configuration>

L’élément Web.config s du <authentication> fichier a également été configuré pour prendre en charge l’authentification basée sur les formulaires.

<configuration>
    <system.web>
        ...

        <authentication mode="Forms" />

        ...
    </system.web>
</configuration>

Limitation de l’accès aux pages d’administration

ASP.NET facilite l’octroi ou le refus d’accès à un fichier ou dossier particulier par utilisateur ou par rôle via sa fonctionnalité d’autorisation d’URL . (Nous avons brièvement abordé l’autorisation d’URL dans le didacticiel Principales différences entre IIS et le serveur de développement ASP.NET et nous avons montré comment IIS et le serveur de développement ASP.NET appliquent les règles d’autorisation d’URL différemment pour le contenu statique et dynamique.) Étant donné que nous voulons interdire l’accès au dossier à l’exception ~/Admin des utilisateurs dans le rôle Administration, nous devons ajouter des règles d’autorisation d’URL à ce dossier. Plus précisément, les règles d’autorisation d’URL doivent autoriser les utilisateurs dans le rôle Administration et refuser tous les autres utilisateurs. Pour ce faire, ajoutez un Web.config fichier au ~/Admin dossier avec le contenu suivant :

<?xml version="1.0"?>
<configuration>
    <system.web>
        <authorization>
            <allow roles="Admin" />
            <deny users="*" />
        </authorization>
    </system.web>
</configuration>

Pour plus d’informations sur ASP.NET fonctionnalité d’autorisation d’URL et sur la façon de l’utiliser pour énoncer les règles d’autorisation pour les utilisateurs et les rôles, veillez à lire les didacticiels Autorisation basée sur l’utilisateur et Autorisation basée sur les rôles de mes tutoriels sur la sécurité du site web.

Déploiement d’une application web qui utilise Application Services

Lors du déploiement d’un site web qui utilise des services d’application et d’un fournisseur qui stocke les informations des services d’application dans une base de données, il est impératif que les objets de base de données nécessaires aux services d’application soient créés sur la base de données de production. Initialement, la base de données de production ne contient pas ces objets. Par conséquent, lorsque l’application est déployée pour la première fois (ou lorsqu’elle est déployée pour la première fois après l’ajout de services d’application), vous devez prendre des mesures supplémentaires pour obtenir ces objets de base de données requis sur la base de données de production.

Un autre défi peut se poser lors du déploiement d’un site web qui utilise des services d’application si vous envisagez de répliquer les comptes d’utilisateur créés dans l’environnement de développement dans l’environnement de production. Selon la configuration Appartenance et Rôles, il est possible que même si vous copiez correctement les comptes d’utilisateur créés dans l’environnement de développement dans la base de données de production, ces utilisateurs ne puissent pas se connecter à l’application web en production. Nous allons examiner la cause de ce problème et discuter de la façon d’éviter qu’il ne se produise.

ASP.NET est fourni avec un outil WSAT (Web Site Administration Tool) qui peut être lancé à partir de Visual Studio et permet de gérer le compte d’utilisateur, les rôles et les règles d’autorisation via une interface web. Malheureusement, le WSAT ne fonctionne que pour les sites web locaux, ce qui signifie qu’il ne peut pas être utilisé pour gérer à distance les comptes d’utilisateur, les rôles et les règles d’autorisation pour l’application web dans l’environnement de production. Nous allons examiner différentes façons d’implémenter un comportement de type WSAT à partir de votre site web de production.

Ajout des objets de base de données à l’aide de aspnet_regsql.exe

Le tutoriel Déploiement d’une base de données a montré comment copier les tables et les données de la base de données de développement vers la base de données de production, et ces techniques peuvent certainement être utilisées pour copier les objets de base de données des services d’application vers la base de données de production. Une autre option est l’outil aspnet_regsql.exe , qui ajoute ou supprime les objets de base de données application services d’une base de données.

Notes

L’outil aspnet_regsql.exe crée les objets de base de données sur une base de données spécifiée. Il ne migre pas les données de ces objets de base de données de la base de données de développement vers la base de données de production. Si vous voulez copier les informations de compte d’utilisateur et de rôle dans la base de données de développement vers la base de données de production, utilisez les techniques décrites dans le didacticiel Déploiement d’une base de données .

Voyons comment ajouter les objets de base de données à la base de données de production à l’aide de l’outil aspnet_regsql.exe . Commencez par ouvrir Windows Explorer et accédez au répertoire .NET Framework version 2.0 sur votre ordinateur, %WINDIR%\ Microsoft.NET\Framework\v2.0.50727. Vous devriez y trouver l’outil aspnet_regsql.exe . Cet outil peut être utilisé à partir de la ligne de commande, mais il comprend également une interface utilisateur graphique ; double-cliquez sur le aspnet_regsql.exe fichier pour lancer son composant graphique.

L’outil commence par afficher un écran de démarrage expliquant son objectif. Cliquez sur Suivant pour passer à l’écran « Sélectionner une option d’installation », qui est illustré dans la figure 1. À partir de là, vous pouvez choisir d’ajouter les objets de base de données des services d’application ou de les supprimer d’une base de données. Étant donné que nous voulons ajouter ces objets à la base de données de production, sélectionnez l’option « Configurer SQL Server pour les services d’application », puis cliquez sur Suivant.

Figure 1 : Choisir de configurer SQL Server pour Les services d’application (cliquer pour afficher l’image en taille réelle)

Dans l’écran « Sélectionner le serveur et la base de données », vous invite à entrer des informations pour vous connecter à la base de données. Entrez le serveur de base de données, les informations d’identification de sécurité et le nom de la base de données qui vous a été fourni par votre société d’hébergement web, puis cliquez sur Suivant.

Notes

Après avoir entré votre serveur de base de données et vos informations d’identification, vous pouvez obtenir une erreur lors du développement de la liste déroulante de base de données. L’outil aspnet_regsql.exe interroge la sysdatabases table système pour récupérer une liste de bases de données sur le serveur, mais certaines sociétés d’hébergement web verrouillent leurs serveurs de base de données afin que ces informations ne soient pas disponibles publiquement. Si vous obtenez cette erreur, vous pouvez taper le nom de la base de données directement dans la liste déroulante.

Figure 2 : Fournir l’outil avec les informations de connexion de votre base de données (cliquez pour afficher l’image en taille réelle)

L’écran suivant récapitule les actions sur le point d’avoir lieu, à savoir que les objets de base de données des services d’application vont être ajoutés à la base de données spécifiée. Cliquez sur Suivant pour effectuer cette action. Après quelques instants, l’écran final s’affiche, notant que les objets de base de données ont été ajoutés (voir la figure 3).

Figure 3 : Réussite ! Les objets de base de données Application Services ont été ajoutés à la base de données de production (cliquez pour afficher l’image en taille réelle)

Pour vérifier que les objets de base de données application services ont été correctement ajoutés à la base de données de production, ouvrez SQL Server Management Studio et connectez-vous à votre base de données de production. Comme le montre la figure 4, vous devez maintenant voir les tables de base de données des services d’application dans votre base de données, aspnet_Applications, aspnet_Membership, aspnet_Userset ainsi de suite.

Figure 4 : Confirmer que les objets de base de données ont été ajoutés à la base de données de production (cliquez pour afficher l’image en taille réelle)

Vous devez uniquement utiliser l’outil lors du aspnet_regsql.exe déploiement de votre application web pour la première fois ou pour la première fois après avoir commencé à utiliser les services d’application. Une fois ces objets de base de données sur la base de données de production, ils n’ont pas besoin d’être ajoutés ou modifiés.

Copie de comptes d’utilisateur du développement vers la production

Lorsque vous utilisez les SqlMembershipProvider classes de fournisseur et SqlRoleProvider pour stocker les informations des services d’application dans une base de données SQL Server, les informations de compte d’utilisateur et de rôle sont stockées dans diverses tables de base de données, notamment aspnet_Users, aspnet_Membership, aspnet_Roleset , entre aspnet_UsersInRolesautres. Si, pendant le développement, vous créez des comptes d’utilisateur dans l’environnement de développement, vous pouvez répliquer ces comptes d’utilisateur en production en copiant les enregistrements correspondants à partir des tables de base de données applicables. Si vous avez utilisé l’Assistant Publication de base de données pour déployer les objets de base de données des services d’application, vous avez peut-être également choisi de copier les enregistrements, ce qui aurait pour effet que les comptes d’utilisateur créés en développement soient également en production. Toutefois, en fonction de vos paramètres de configuration, vous pouvez constater que les utilisateurs dont les comptes ont été créés en développement et copiés en production ne peuvent pas se connecter à partir du site web de production. Quelle en est la raison ?

Les SqlMembershipProvider classes de fournisseur et SqlRoleProvider ont été conçues de telle sorte qu’une base de données unique puisse servir de magasin d’utilisateurs pour plusieurs applications, où chaque application peut, en théorie, avoir des utilisateurs avec des noms d’utilisateur et des rôles qui se chevauchent avec le même nom. Pour permettre cette flexibilité, la base de données conserve une liste d’applications dans la aspnet_Applications table, et chaque utilisateur est associé à l’une de ces applications. Plus précisément, la aspnet_Users table a une ApplicationId colonne qui lie chaque utilisateur à un enregistrement dans la aspnet_Applications table.

En plus de la ApplicationId colonne, la aspnet_Applications table inclut également une ApplicationName colonne, qui fournit un nom plus convivial pour l’application. Lorsqu’un site web tente d’utiliser un compte d’utilisateur, par exemple en validant les informations d’identification d’un utilisateur à partir de la page de connexion, il doit indiquer à la SqlMembershipProvider classe avec quelle application utiliser. Il le fait généralement en fournissant le nom de l’application, et cette valeur provient de la configuration du fournisseur dans Web.config , en particulier via l’attribut applicationName .

Mais que se passe-t-il si l’attribut applicationName n’est pas spécifié dans Web.config? Dans ce cas, le système d’appartenance utilise le chemin d’accès racine de l’application applicationName comme valeur. Si l’attribut applicationName n’est pas explicitement défini dans Web.config, il est possible que l’environnement de développement et l’environnement de production utilisent une racine d’application différente et soient donc associés à des noms d’application différents dans les services d’application. Si une telle incompatibilité se produit, les utilisateurs créés dans l’environnement de développement auront une ApplicationId valeur qui ne correspond pas à la ApplicationId valeur de l’environnement de production. Le résultat net est que ces utilisateurs ne pourront pas se connecter.

Notes

Si vous vous trouvez dans cette situation , avec des comptes d’utilisateur copiés en production avec une valeur incompatible ApplicationId , vous pouvez écrire une requête pour mettre à jour ces valeurs incorrectes ApplicationId sur le ApplicationId utilisé en production. Une fois la mise à jour, les utilisateurs dont les comptes ont été créés sur l’environnement de développement peuvent désormais se connecter à l’application web en production.

La bonne nouvelle est qu’il existe une étape simple que vous pouvez prendre pour vous assurer que les deux environnements utilisent le même ApplicationId : définissez explicitement l’attribut applicationName dans Web.config pour tous vos fournisseurs de services d’application. J’ai explicitement défini l’attribut applicationName sur « BookReviews » dans les éléments et <roleManager> comme le <membership> montre cet extrait de code.Web.config

<membership defaultProvider="ReviewMembership">
    <providers>
        <clear />

        <add type="System.Web.Security.SqlMembershipProvider" 
             name="ReviewMembership" 
             connectionStringName="ReviewsConnectionString" 
             applicationName="BookReviews" />
    </providers>
</membership>

Pour plus d’informations sur la définition de l’attribut applicationName et sa logique, reportez-vous au billet de blog de Scott Guthrie , Toujours définir la propriété applicationName lors de la configuration de ASP.NET Membership et d’autres fournisseurs.

Gestion des comptes d’utilisateur dans l’environnement de production

L’outil WSAT (Web Site Administration Tool) ASP.NET facilite la création et la gestion de comptes d’utilisateur, la définition et l’application de rôles, ainsi que l’orthographe des règles d’autorisation basées sur les utilisateurs et les rôles. Vous pouvez lancer le WSAT à partir de Visual Studio en accédant à l’Explorateur de solutions et en cliquant sur l’icône configuration ASP.NET ou en accédant aux menus Site web ou Projet et en sélectionnant l’élément de menu Configuration ASP.NET. Malheureusement, le WSAT ne peut fonctionner qu’avec des sites web locaux. Par conséquent, vous ne pouvez pas utiliser le WSAT à partir de votre station de travail pour gérer le site web dans l’environnement de production.

La bonne nouvelle est que toutes les fonctionnalités exposées par le WSAT sont disponibles par programme via les API Appartenance et Rôles ; en outre, la plupart des écrans WSAT utilisent les contrôles standard ASP.NET connexion. En bref, vous pouvez ajouter ASP.NET pages à votre site web qui offrent les fonctionnalités de gestion nécessaires.

Rappelez-vous qu’un didacticiel précédent a mis à jour l’application web Book Reviews pour inclure un ~/Admin dossier, et que ce dossier a été configuré pour autoriser uniquement les utilisateurs dans le rôle Administration. J’ai ajouté une page à ce dossier nommée CreateAccount.aspx à partir de laquelle un administrateur peut créer un compte d’utilisateur. Cette page utilise le contrôle CreateUserWizard pour afficher l’interface utilisateur et la logique back-end pour créer un compte d’utilisateur. De plus, j’ai personnalisé le contrôle pour inclure un contrôle CheckBox qui demande si le nouvel utilisateur doit également être ajouté au rôle Administration (voir la figure 5). Avec un peu de travail, vous pouvez créer un ensemble personnalisé de pages qui implémente les tâches liées à la gestion des utilisateurs et des rôles qui seraient autrement fournies par le WSAT.

Notes

Pour plus d’informations sur l’utilisation des API Appartenance et Rôles, ainsi que des contrôles web ASP.NET liés à la connexion, consultez mes didacticiels sur la sécurité du site web. Pour plus d’informations sur la personnalisation du contrôle CreateUserWizard, consultez les didacticiels Création de comptes d’utilisateur et stockage d’informations utilisateur supplémentaires, ou case activée l’article d’Erich Peterson, Personnalisation du contrôle CreateUserWizard.

Figure 5 : Les administrateurs peuvent créer des comptes d’utilisateur (cliquer pour afficher l’image en taille réelle)

Si vous avez besoin de toutes les fonctionnalités de WSAT case activée déploiement de votre propre outil d’administration de site web, dans lequel l’auteur Dan Clem décrit le processus de création d’un outil de type WSAT personnalisé. Dan partage le code source de son application (en C#) et fournit des instructions pas à pas pour l’ajouter à votre site web hébergé.

Résumé

Lors du déploiement d’une application web qui utilise l’implémentation de la base de données des services d’application, vous devez d’abord vérifier que la base de données de production dispose des objets de base de données requis. Ces objets peuvent être ajoutés à l’aide des techniques décrites dans le didacticiel Déploiement d’une base de données ; vous pouvez également utiliser l’outil aspnet_regsql.exe , comme nous l’avons vu dans ce tutoriel. D’autres défis que nous avons abordés concernent la synchronisation du nom d’application utilisé dans les environnements de développement et de production (ce qui est important si vous souhaitez que les utilisateurs et les rôles créés dans l’environnement de développement soient valides en production) et les techniques de gestion des utilisateurs et des rôles dans l’environnement de production.

Bonne programmation!

En savoir plus

Pour plus d’informations sur les sujets abordés dans ce didacticiel, consultez les ressources suivantes :

• Outil d’inscription ASP.NET SQL Server (aspnet_regsql.exe)
• Création de la base de données Application Services pour SQL Server
• Création du schéma d’appartenance dans SQL Server
• Examen d’ASP. Appartenance, rôles et profil de NET
• Déploiement de votre propre outil d’administration de site web
• Tutoriels sur la sécurité des sites web
• Vue d’ensemble de l’outil d’administration de site web

Next