|
Impersonate()
|
|||
---|---|---|---|
#18+
Думал, что это отсюда , но, как оказалось , все гораздо гораздее... ЭстЪ идеи? _________________ "Helo, word!" - 17 errors 56 warnings Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2015, 17:39 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
ты что сделать-то хочешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2015, 17:47 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
> ты что сделать-то хочешь? прокинуть пользователя, залогинившегося посредством Forms Authentication, на SQL сервант с Код: c# 1.
_________________ "Helo, word!" - 17 errors 56 warnings Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2015, 08:45 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
Ходить в базу от имени текущего доменного пользователя - дурной тон. Проблем с этим масса (сложная систама управления правами, не очеидный аудит, прямой доступ в БД мимо вашего ПО и т.д.). Best practice: иметь выделнного доменного пользователя или использовать SQL Server Authorization (по прямому логину/паролю). Если есть необходимость в БД передавать текущего пользователя приложения, лучше делать это явно параметром запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2015, 09:20 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
> Ходить в базу от имени текущего доменного пользователя - дурной тон. Во-первых: не текущего доменного пользователя, а "пользователя, залогинившегося посредством Forms Authentication". Т.е. он может зайти на машу под одной учеткой, а на сайте ралогиниться - под другой. Во-вторых: это не в моей власти. Как говорится "...маємо те, що маємо..." На SQL серванте, как раз, доступ и раздаёцо союзно с пользователем, который при'connect'ился к нему. > Best practice: иметь выделнного доменного пользователя не получается - см.выше > или использовать SQL Server Authorization (по прямому логину/паролю). Да - но тогда нужно знать и хранить где-то пороль (причем в открытом виде), дабы подсунуть его со всеми вытекающими... > Если есть необходимость в БД передавать текущего пользователя приложения, лучше делать это явно параметром запроса гм... и как сие можно забалабенить при подключении к OLAP'у? _________________ "Helo, word!" - 17 errors 56 warnings Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2015, 09:44 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
Ex_Soft, https://msdn.microsoft.com/en-us/library/ff650469.aspx https://msdn.microsoft.com/en-us/library/ms998355.aspx вроде оно ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2015, 10:11 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
zz118Ходить в базу от имени текущего доменного пользователя - дурной тон. Пруф? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2015, 22:42 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
MrVoid, User-level authorization affects the overall scalability of the application because it defeats connection pooling. You should not take this route unless strictly necessary. In general, a "trusted model" based on roles and using a fixed number of user-independent accounts alleviates this issue while maintaining a certain association between users and functions. боянъ, но написано подробно ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2015, 09:14 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
zz118, авторaffects the overall scalability и причём здесь дурной тон? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2015, 10:05 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
@zz118 Представми, что в конторе 5000 пользователей. 4900 пользователей можно разбить по группам (100 групп по 49 человек). У остальных 100 - уникальные права. Как вы будете управлять пользователями через SQL Login? Напишите сценарий. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2015, 10:40 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
MrVoid@zz118 Представми, что в конторе 5000 пользователей. 4900 пользователей можно разбить по группам (100 групп по 49 человек). У остальных 100 - уникальные права. Как вы будете управлять пользователями через SQL Login? Напишите сценарий. :) Очевидно, альтернативой считается "выплевывать" SQL exception в пользователся? толково=) Я уже молчу про O/R map cache, который живет "мимо" секьюрити модели приложения. На мой взгляд, сценарий простой: управление пользователями - дело сервера приложений, но никак на базы данных. Вот пусть сервак занимается сессиями, авторизацией, эффективными пермиссиями и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2015, 21:02 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
zz118, серебрянной пули - не существует ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2015, 21:41 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
Изопропил, Кто же спорит, просто, по моему опыту, попытки задешево сделать модель первмиссий на стороне SQL сервера ни разу не приводили к успеху. Вариантов то масса: сервер приложений federated security выделенный сервер использование AD (кстати, в этом случае все получается достаточно изящно, можно глянуть реализацию у Atlassian) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2015, 08:41 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
zz118попытки задешево сделать модель первмиссий на стороне SQL сервера ни разу не приводили к успеху. как я понял, топикстартеру оно уже досталось в готовом виде ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2015, 09:32 |
|
Impersonate()
|
|||
---|---|---|---|
#18+
zz118Ходить в базу от имени текущего доменного пользователя - дурной тон. Проблем с этим масса (сложная систама управления правами, не очеидный аудит, прямой доступ в БД мимо вашего ПО и т.д.). Best practice: иметь выделнного доменного пользователя или использовать SQL Server Authorization (по прямому логину/паролю). Если есть необходимость в БД передавать текущего пользователя приложения, лучше делать это явно параметром запроса Всё это правильно. Но, представим себе такое: В базе по датабазе ролям назначены некие права, обычно это может идти еще от систем клиент-сервер, к которым прикручен средний слой, в виде веб-сервиса. И оба варианта c-s c-ws-s должны работать. Вот тут я возникает задача как у ТС. Я сам такой. Для планируемых с 0 систем можно дизайнировать, а в таких случаях - имеем то, что имеем. И только реальный юзер домена знает свои права в базе. Следовательно - он должен быть залогинен на SQL Server. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2015, 15:58 |
|
|
start [/forum/topic.php?fid=20&fpage=82&tid=1401417]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 323ms |
total: | 462ms |
0 / 0 |