Переносима ли база данных членства .Net или учетные записи каким-то образом привязаны к исходному веб-сайту или серверу?

У меня есть веб-сайт ASP.Net, использующий членство .Net с поставщиком SQL Server, поэтому пользователи и роли хранятся в таблицах SQL, созданных Aspnet_regsql.exe.

Является ли эта архитектура полностью автономной и переносимой, или пользователи в ней каким-то образом привязаны к конкретному веб-сайту, на котором они создают свою учетную запись?

Другими словами, если мы создадим группу пользователей в dev или UAT, должна ли она по-прежнему работать нормально, резервное копирование и восстановление этой базы данных на другой сервер, доступный под другим доменным именем?

Мы наблюдаем странное поведение при перемещении базы данных, например, когда пользователи теряют принадлежность к группе и тому подобное, и мне любопытно, насколько портативна и не зависит от среды эта база данных. У меня есть подозрение, что что-то привязано к машинному ключу или домену.


membership asp.net-membership membership-provider sqlmembershipprovider
person Deane    schedule 23.04.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Да, они должны работать нормально.

Единственное место, где вам нужно быть осторожным, - это управление паролями. поставщики членства в .Net могут использовать машинные ключи для шифрования или хеширования паролей. Но есть обходной путь, когда вы указываете приложению asp.net использовать конкретный машинный ключ, а не автоматически сгенерированные машинные ключи.

В моем приложении я храню свои пароли в зашифрованном виде, и я указал свой машинный ключ, как показано ниже, для шифрования / дешифрования. Когда я это сделаю, я могу легко перенести свою базу данных разработки на производственный сервер или также легко перенести базу данных с одного производственного сервера на другой.

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

Вам больше не о чем беспокоиться относительно миграции при работе с MembershipProviders.

person this. __curious_geek    schedule 23.04.2010
comment
Если вы этого не сделали и просто позволили провайдеру иметь пароли с автоматически сгенерированным машинным ключом, есть ли способ исправить это? Я не знаю, является ли это моей проблемой, но если мы предположим, что хэш пароля был специфическим для конкретной машины ... что вы с этим сделаете? - person Deane; 23.04.2010
comment
На самом деле я никогда не разбирался в этой ситуации, так как мы активно занимались этим, делая это таким образом. Я думаю, в вашем случае вы сможете получить ключ машины из machine.config. Напишу сюда, если найду что-нибудь полезное по этой теме. - person this. __curious_geek; 23.04.2010

arrow_upward
0
arrow_downward

Пользователи привязаны к имени приложения. Вы можете проверить это и увидеть, соответствует ли имя приложения, с которым связан каждый пользователь, имени приложения в файле web.config на вашем рабочем сервере.

Кроме того, когда вы переносите членство в другую базу данных, вы должны убедиться, что берете не только таблицы, но и все хранимые процедуры. Если по какой-либо причине вы просто переносите схему базы данных, перед переносом необходимо запустить Aspnet_regsql.exe.

person Daniel C.S.    schedule 23.04.2010
comment
Но в ситуации резервного копирования и восстановления все сохраненные процессы все равно не будут восстановлены? - person Deane; 23.04.2010