из триггера, как узнать, кто изменил данные в таблице X, когда этот пользователь вошел в систему из универсального dbuser, но получил права из пользовательской таблицы

Question

Я не уверен, как сформулировать этот вопрос, но:

1. у вас есть веб-страница

2. веб-страница получила определенного пользователя / пароль в файле web.config для строки подключения

3. на веб-странице, которую вы запрашиваете пользователя / пароль, который связан с таблицей (id, name, pass)

4. пользователь распознается как действительный пользователь / пароль, и теперь вы знаете идентификатор из таблицы выше

5. пользователь изменил некоторые данные в таблице, и эта таблица получила триггер

из этого триггера, как получить идентификатор пользователя из шага 4

Допустим, пользователь вошел в систему с помощью таблицы членства asp.net

Answer 1

Используйте SET CONTEXT_INFO и CONTEXT_INFO() для передачи внеполосных параметров. Ваш веб-слой должен убедиться, что он устанавливает это правильно для каждого соединения, которое он использует, перед вызовом в базу данных, что означает один дополнительный дополнительный обход в базу данных.

Answer 2

Как уже было предложено (Ремусом Русану), используя SET CONTEXT_INFO, это означает, что вам не нужно добавлять параметры для всех ваших сохраненных процедур, чтобы сделать это. Подобный вопрос от меня можно найти здесь:

SQL Server: изменение свойства «Имя приложения» для целей аудита

Answer 3

Поскольку имя пользователя - это просто данные, трудно перехватить через триггер.

Вариант # 1 аналогичен тому, что сказал KM, и ваш разработчик должен будет передать имя пользователя с помощью запроса и обновить столбец аудита в базе данных. и триггер будет захватывать этот столбец обновлений и делать с ним все, что вы захотите.

Вариант № 2 будет состоять в том, чтобы программно создать пользователя на сервере SQL или в структуре вашего домена Windows, предоставить ему доступ к приложению и затем выдать себя за этого пользователя при входе для последующих входов в систему. Это может быть проблемой административного обслуживания, но пользователи приложения затем получат доступ к базе данных, используя свой уникальный идентификатор вместо идентификатора, настроенного в web.config, и все обновления базы данных будут такими же, как у общего пользователя, а не в общем, представленном в web.config. .

Надеюсь, это поможет.

Answer 4

@ KM, или переместите своих пользователей в AD и используйте встроенную аутентификацию. Здесь нет другого варианта.

Answer 5

На шаге 4, когда вы говорите, что ВЫ это знаете, вы на самом деле имеете в виду, что ваше приложение знает, какой идентификатор пользователя вошел в систему. Аутентификация вашего приложения полностью отделена от вашей аутентификации базы данных (за исключением, возможно, использования аутентификации Windows с SQL-сервером , но я не думаю, что это то, что вы делаете).

Как упоминает КМ, вам нужно будет передать идентификатор пользователя приложения в триггер с помощью столбца "LastUpdatedUserID" или чего-то подобного в обновляемой таблице.

Answer 6

вам нужно иметь столбец LastChgID (или аналогичный) в таблице, которую они меняют в зависимости от имени пользователя / пароля веб-страницы, после чего вам сообщит INSERTED.LastChgID. в противном случае вам не повезло.

EDIT Когда вы сохраняете изменение, сохраняете идентификатор пользователя веб-приложений в столбце LastChgID таблицы, для этого может потребоваться передать его в хранимую процедуру или просто УСТАНОВИТЬ этот столбец в операторе UPDATE. Когда триггер сработает, INSERTED.LastChgID будет иметь идентификатор пользователя веб-приложений.