Une base de données d'appartenance .Net est-elle portable ou les comptes sont-ils liés au site Web ou au serveur d'origine?

Question

J'ai un site Web ASP.Net utilisant l'appartenance .Net avec un fournisseur SQL Server, de sorte que les utilisateurs et les rôles sont stockés dans les tables SQL créées par Aspnet_regsql.exe.

Cette architecture est-elle totalement autonome et portable, ou les utilisateurs sont-ils en quelque sorte liés au site Web spécifique sur lequel ils créent leur compte? En d'autres termes, si nous créons un groupe d'utilisateurs en dev ou en UAT, sauvegardez et restaurez cette base de données sur un autre serveur, accessible sous un autre nom de domaine, devrait-il encore fonctionner?

Nous observons un comportement étrange lorsque nous déplaçons la base de données, comme les utilisateurs perdant l'affiliation de groupe et autres, et je suis curieux de savoir si cette base de données est portable et indépendante de l'environnement. Je soupçonne que quelque chose est lié à la clé de la machine ou au domaine.

Answer 1

Oui, ils devraient fonctionner correctement.

Seul l'endroit où vous devez faire attention est gestion de mot de passe. .Net Les fournisseurs d'appartenance peuvent utiliser des clés spécifiques à l'ordinateur pour crypter ou hacher les mots de passe. Mais il existe une solution de contournement où vous dites à l'application asp.net d'utiliser une clé machine spécifique et non les clés spécifiques à la machine générées automatiquement.

Dans mon application, je garde mes mots de passe cryptés et j'ai spécifié ma machine-clé comme ci-dessous pour le cryptage/décryptage. Quand je fais ceci, je peux porter ma base de données de développement au serveur de production ou migrer également la base de données d'un serveur de production à l'autre très facilement.

<machineKey validationKey="<your-validation-key>" decryptionKey="<your-decryption-key>" validation="SHA1"/> 

Il n'y a rien d'autre à redire concernant la migration lorsque vous travaillez avec MembershipProviders.

Answer 2

Les utilisateurs sont liés au nom de l'application. Vous pouvez le vérifier et voir si le nom de l'application auquel chaque utilisateur est lié correspond au nom de l'application sur le fichier web.config sur votre serveur de production. En dehors de cela, lorsque vous portez l'appartenance à une autre base de données, vous devez vous assurer que vous prenez non seulement des tables mais aussi toutes les procédures stockées. Si, pour une raison quelconque, vous ne faites que porter votre schéma de base de données, vous devez exécuter Aspnet_regsql.exe avant de le porter.