ASP.Net Membership.DeleteUser - PullRequest
       18

ASP.Net Membership.DeleteUser

8 голосов
/ 23 января 2009

В тестировании пользователь на БД, который я использовал, был большим дураком. На производстве у него есть только Execute.

Когда я позвонил,

Membership.DeleteUser(user)

В тестировании все заработало. Я пробую то же самое в производстве, и я получаю это:

Оператор DELETE конфликтует с ограничением REFERENCE. "FK__aspnet_Us__UserI__37703C52". Конфликт произошел в базе данных «Тестирование», таблица «dbo.aspnet_UsersInRoles», столбец «UserId».

В своих поисках (поисках в Google) я наткнулся на эту ссылку где чувак говорил,

Ошибка: оператор DELETE конфликтовал с ограничением ССЫЛКА "FK__aspnet_Me__UserI__15502E78". конфликт произошел в базе данных "YourDBName", таблица столбец "dbo.aspnet_Membership" 'UserId'.

Мне понадобилось время, чтобы найти решение это через несколько сайтов и вариантов как ошибка и возможные решения были довольно обманчивы. Оказывается, при по крайней мере в моем случае это была проблема с разрешениями на членство база данных. Пользователь, которого я использую для подключиться имел доступ к просмотру детали членства в базе данных само по себе, но как часть aspnet_Users_DeleteUser сохранен Процедура, которую он выбирает из таблица системных объектов. Членство пользователь связи видимо не сделал иметь достаточные права для этого выберите, чтобы полное удаление не удалось.

Исправление для меня было добавить пользователя в роль aspnet_Membership_FullAccess для базы данных членства.

Но когда я это сделал, это не сработало. У кого-нибудь есть идеи, как с этим бороться?

Ответы [ 7 ]

7 голосов
/ 08 июля 2010

После небольшой проверки я обнаружил, что проблема заключается в следующей строке хранимой процедуры aspnet_Users_DeleteUser:

IF ((@TablesToDeleteFrom & 1) <> 0 AND
    (EXISTS (SELECT name FROM sysobjects WHERE (name = N'vw_aspnet_MembershipUsers') AND (type = 'V'))))

Есть еще 3 аналогичные строки для 3 других таблиц. Проблема заключается в том, что если пользователь, выполняющий сохраненный процесс, не имеет доступа к vw_aspnet_MembershipUsers, он не появится при выборе из sysobjects. Мне любопытно узнать, почему все это утверждение EXISTS необходимо.

Несмотря на это, в следующем обсуждении « Доступ к системным объектам для просмотра пользовательских таблиц без доступа к пользовательским таблицам непосредственно в SQL Server Security » содержит ответ. Предоставляя «ПРОСМОТР ОПРЕДЕЛЕНИЯ» для рассматриваемых представлений, операторы EXISTS теперь будут успешными, и вам не придется предоставлять ненужные, нежелательные или чрезмерные разрешения пользователю в строке подключения вашего приложения.

5 голосов
/ 28 апреля 2009

У меня также была эта проблема, и она была вызвана отсутствием представлений, чтобы исправить, я просто использовал сценарий создания из другой базы данных и заново создал все представления vw_aspnet_ *.

4 голосов
/ 23 января 2009

ОК, угадайте что? Я прочитал это: http://forums.asp.net/t/1254087.aspx

Хорошо, через несколько минут после отправки моего сообщения Я нашел решение :) Получается что ВЫБЕРИТЕ РАЗРЕШЕНИЕ должно быть добавлено для пользователя ASPNET на vw_aspnet_MembershipUsers view.

Но до сих пор остается загадкой, почему я не получить ошибку об отсутствии разрешение. Заявление EXIST было просто возвращая ложь.

и дал производственному пользователю разрешение SELECT и вуаля! Оно работает! Спасибо, ребята!

2 голосов
/ 23 января 2009

Я считаю, что ваше ограничение 'REFERENCE' на самом деле является внешним ключом в базе данных, который существует между таблицей aspnet_Users и таблицей aspnet_UsersInRoles. Я бы подумал, что пользователь, которого вы пытаетесь, имеет свой UserId в обеих таблицах, и прежде чем вы сможете удалить его из таблицы Users, его также необходимо удалить из таблицы UsersInRoles.

Вы пытались http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.removeusersfromroles.aspx, чтобы убедиться, что все роли удалены от этого пользователя? Вы также можете проверить, проверив строки этих двух таблиц в базе данных.

1 голос
/ 09 апреля 2009

Если ошибка (или аналогичная) по-прежнему сохраняется после предоставления SELECT для пользователя ASP на vw_aspnet_MembershipUsers, вы можете захотеть предоставить SELECT для некоторых других vw_aspnet _ ???? просмотров тоже. Особенно "профиль" и "UsersInRoles". В противном случае - по некоторым причинам SP DeleteUser SP получает пустой результат при ВЫБОРЕ из этих представлений и отказывается сначала удалить существующие записи из них.

0 голосов
/ 29 июня 2016

Я решил это, удалив строку в proc, которая проверяет вид. У меня нет никаких представлений о членстве в asp, и они мне нигде не нужны, поэтому кажется, что создавать представление просто бессмысленно, чтобы строка кода могла возвращать true - процесс фактически не использует представление. Возможно, если вы используете больше возможностей объектов членства, вам может понадобиться представление для чего-то другого. В любом случае проверка существования представления кажется странным способом для процесса решить, есть ли в таблице aspnet_membership строка, которую нужно удалить.

IF ((@TablesToDeleteFrom & 1) <> 0 
    )
    --AND
    --   (EXISTS (SELECT name FROM sysobjects WHERE (name = N'vw_aspnet_MembershipUsers') AND (type = 'V'))))
0 голосов
/ 01 июня 2016

Может быть, лучше убедиться, что пользователь, выполняющий удаление, имеет право исправлять роли ASP.NET Membership sql. В моем случае я удалял пользователя членства, который имеет некоторые роли и свойства профиля. Метод удаления не удался, но после назначения правильных ролей sql он сработал.

ALTER ROLE [aspnet_Profile_FullAccess] ADD MEMBER [<YOUR SQL USER>]
ALTER ROLE [aspnet_Roles_FullAccess] ADD MEMBER [<YOUR SQL USER>]

Вы также можете добавить [aspnet_Personalization_FullAccess], если вы используете эту функцию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...