Ограничение LINQ2SQL Datacontext для конкретной роли приложения SQL - PullRequest
0 голосов
/ 07 апреля 2009

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

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

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

1 Ответ

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

Мои выводы (смотри почему):

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

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

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

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

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

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


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

Одна из проблем заключается в том, что он плохо работает с пулами соединений. Это независимо от linq2sql. См. В конце это в MSDN.

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

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

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

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