Ограничить LINQ2SQL Datacontext для конкретной роли приложения SQL

Question

В SQL Server вы можете иметь защиту роли приложения, с помощью которой вы можете, например, предоставить определенные разрешения, которые исходят из определенных приложений.

Вы можете выполнить sp_SetAppRole(), чтобы установить роль приложения, но задавался вопросом, как это можно сделать при использовании LINQ2SQL datacontext с наименьшим количеством трения.

Я видел эту ссылку: http://social.msdn.microsoft.com/Forums/en-US/linqprojectgeneral/thread/e25e98a6-b0ac-42fc-b70c-2b269a7fa1cb, но надеялся, что для более чистого подхода/

Answer 1

Мои conclussions (см ниже раздел для почему):

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

Альтернатива SQL отнимает много преимуществ от использования linq, поскольку она полагается на SP.

Моя рекомендация:

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

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

Если вы все еще хотите продолжить подход, отключите объединение пулов. Чтобы уменьшить открытые/закрытые служебные данные, откройте подключения явно.

---

Полное объяснение/ссылки:

Один вопрос заключается в том, что не очень хорошо играет с пулом подключений. Это независимо от linq2sql. См. В конце this в msdn.

Существует 2 варианта с SQL Server 2005 (msdn link), один из них также упоминается в теме, к которой вы привязались, но также указывает, что это может пойти не так.

Обратите внимание, что его незащищенный вариант в сценарии с двумя уровнями, например, когда приложение, используемое клиентами, подключается непосредственно к sql. В этих случаях pwd для любого приложения на компьютере клиента будет отображаться в них. Он более безопасен, если это бизнес-уровень, который соединяется, но это именно тот случай, когда вы действительно хотите объединить пулы.

Другая альтернатива, упомянутая в моей второй ссылке на msdn, хорошо работает с пулом соединений. Он основан на хранимых процедурах и инструкции execute as. Выполнение as вызывается внутри процедуры, и после выполнения процедуры возвращается контекст. Это здорово, но на самом деле это будет отдавать много от того, что вы получаете с linq2sql, перейдя по маршруту sp.