Может ли Entity Framework выполнять хранимые процедуры без доступа к sp_executesql?

#c# #database #entity-framework #permissions #credentials

#c# #База данных #entity-framework #разрешения #учетные данные

Вопрос:

Добрый день всем,

Я унаследовал несколько настольных приложений, которые сильно зависят от хранимых процедур для операций с данными. Эти приложения были написаны на VB6, и в настоящее время я пытаюсь выяснить, как перенести их на .Net 5 или .Net 6.

Я понимаю, что ядро Entity Framework способно выполнять хранимые процедуры. Однако в видео, которое я недавно смотрел, я понял, что Entity Framework Core выполняет функции данных через хранимую процедуру sp_executesql, чтобы обеспечить выполнение любой процедуры, которую разработчик мог динамически сгенерировать.

Однако, как упоминалось в приведенном выше видео, это создает брешь в безопасности для настольных приложений. Чтобы запустить sp_executesql, пользователи настольных приложений должны иметь учетные данные, которые могут запускать его в своей системе. Эти значения могут быть зашифрованы, но шифрование не является неуязвимым.

Если я создам и использую учетные данные базы данных, которые не имеют доступа к sp_executesql, но имеют доступ к хранимым процедурам, созданным моими коллегами, сможет ли Entity Framework запускать последние?

Комментарии:

1. Зачем вам хранимая процедура для выполнения динамически генерируемого SQL? Вам действительно нужна эта возможность? Это можно сделать на клиенте без использования SP.

2. Возможно, мне следовало перефразировать это. Я не пытаюсь использовать динамический сгенерированный sql. Я пытаюсь вызвать SPS моего коллеги через entity framework, чтобы мне не приходилось переделывать всю их работу.

Ответ №1:

Вы можете использовать «необработанный SQL-запрос» для выполнения хранимых процедур напрямую, не требуя sp_executesql :

 var customers = context.Customers.SqlQuery("dbo.sp_getcustomers");
 

или:

 var customers = context.Customers.SqlQuery("dbo.sp_getcustomerbyid @p1", customerID);
 

SqlQuery возвращает отложенную загрузку IEnumerable<T> .

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

Дальнейшее чтение:
Необработанные SQL-запросы (EF6)
к базе данных.Метод SqlQuery

Ответ №2:

Если я создам и использую учетные данные базы данных, которые не имеют доступа к sp_executesql, но имеют доступ к хранимым процедурам, созданным моими коллегами, сможет ли Entity Framework запускать последние?

Предпосылка этого вопроса вдвойне ошибочна.

  1. sp_executesql доступен для всех пользователей и не представляет какой-либо дыры в безопасности. Ваши пользователи будут иметь доступ к sp_executesql.
  2. EF фактически не вызывает sp_executesql. Он вызывает хранимую процедуру как RPC вместо пакета TSQL. Это встроенная функциональность протокола TDS. Но profiler отображает вызов RPC как пакет TSQL с использованием sp_executesql, чтобы вы могли скопировать и вставить вызов в окно запроса для тестирования.