Рекомендации по управлению триггерами таблиц базы данных при использовании сохранения модели django - PullRequest
Новая
       16

Рекомендации по управлению триггерами таблиц базы данных при использовании сохранения модели django

0 голосов
/ 02 апреля 2019

У нас есть устаревшая база данных на основе SQL Server, в которой установлены триггеры для обновления столбцов созданных, созданных, модифицированных и модифицированных при создании строки и ее последующем изменении. Для созданных * столбцов установлены значения по умолчанию, а для измененных * столбцов установлены триггеры.

Это было сделано для управления событиями создания и обновления, происходящими через разные внешние интерфейсы и даже через наборы инструментов SQL Server (SSMS).

Сейчас я создаю внутреннее интерфейсное приложение на основе Django для некоторых из этих таблиц и первоначально использую интерфейс администратора Django для действий на основе CRUD над этими таблицами.

Проблема, с которой я столкнулся, заключается в том, что, поскольку Django Web App подключается к базе данных с использованием учетной записи службы Windows с правами доступа к базе данных, триггер ModifiedBy использует эту учетную запись пользователя обслуживания, а не учетную запись конечного пользователя WebApp для определения того, кто 'обновил строку. Я понимаю почему. Но хотелось бы знать, смог ли кто-нибудь каким-либо образом заставить триггер использовать конечного пользователя веб-приложения, а не учетную запись, используемую для установления соединения изнутри Django?

Установка представляет собой среду Windows, в которой Apache предоставляет веб-хостинг для инфраструктуры Django 2.x. Аутентификация Windows используется против SQL Server. Мы также настроили ADFS, чтобы устранить необходимость повторного ввода учетных данных внутренними пользователями. Вместо этого мы используем членство в группе AD для ограничения или предоставления доступа к приложению.

Триггеры уже существуют, и даже если мы передадим запрос сеанса 'username' модели, он будет перезаписан триггером при его срабатывании после обновления.

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

Я также подумал о том, чтобы как-то использовать конечного пользователя webApp для аутентификации в базе данных, а не для учетной записи службы. Я нашел возможное решение в https://blog.markhepburn.com/2010/02/07/per-user-database-authentication-in-django. Но это зависит от того, сохраняются ли в сеансе учетные данные конечного пользователя в виде простого текста, и, учитывая, что оно было реализовано в 2010 году, я надеялся, что может быть решение, которое является более актуальным .

заранее спасибо

Пример триггера будет что-то вроде 

CREATE TRIGGER [dbo].[TRU_Product_Audit]
ON [dbo].[Product]
AFTER UPDATE
AS 
    BEGIN

        IF(COLUMNS_UPDATED())>0

            BEGIN

                UPDATE pr
                SET pr.ModifiedOn=GETDATE(),
                    pr.ModifiedBy=SUSER_SNAME()
                FROM INSERTED i
                INNER JOIN [dbo].[Product] pr
                ON pr.ProductID=i.ProductID

            END
    END
GO
...