Служба звітності та роль програми

Перший плакат, довгий час тут ховається. Який найкращий спосіб активізувати роль програми у звіті?

Я пробував різні речі, і єдиний метод, який працює, - це вбудувати виклик у роль програми так: -

EXEC sp_setapprole 'REPORTZ', 's3cr3t';
select *
from mytable
where ID < 10000

у наборі даних. Це спрацьовує ... але не на мій смак (звичайно, не в такій формі, яку я хотів би скотитися у виробниче середовище).

Я вважаю за краще, якби я міг якось "викрасти" або "ввести" лінію активації ролі додатків під час виконання або через власні збірки, або, ймовірно, якийсь "гачок сервера" в Службі звітування (що в обох випадках я не маю уявлення, як )

Дуже вдячний за ваш час + добру увагу.

YS.

sql-server ssrs role

— YS.
джерело

ви можете почати звідси msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx, щоб зрозуміти, як розширити Службу звітування (ін'єкційний код, який визначає роль програми), але я не став би цей коментар як відповідь, не впевнений, що це дійсно найпростіший спосіб, і це не вдалося зробити в конфігурації

залежно від того, як люди отримують доступ до цього звіту, ви можете вбудувати облікові дані користувача звіту в набір даних, а потім встановити сторону сервера входу sql, щоб він мав обмежені привілеї.

— DForck42

Вітаю, DForck - вся система базувалася на близькості, і ми хочемо зберегти її таким чином.

Я бачу пару способів, як це можна зробити, не вдаючись до чогось надто фантазійного.

Перший - використовувати інтегровану автентифікацію Windows та призначити дозволи групам, які представляють користувачів програми.
Ви можете створити ролі, які можуть бути надані, а потім скористатися, set roleщоб взяти на себе роль у вашому коді в db. Таким чином, ви не вводите пароль і спочатку перевіряєте додаток.

Перевага першого полягає в тому, що в домені AD легко керувати тим, хто має доступ до програми. Управління було б відносно простим. Основними недоліками було б те, що він обмежився б випадками, коли інтегрований auth має сенс, і вам доведеться підтримувати інтегрований auth весь шлях. Крім того, для кожного переходу потрібна тристороння аутентифікація (між сервером, клієнтом та KDC).

Перевага другого полягає в тому, що це, мабуть, найлегше прошивати, і він не виставляє інформації про безпеку по мережі, і це працює у випадках, коли інтегрований аут не працює добре.

Я б спробував обидва ці підходи, перш ніж спробувати розширити послугу звітності. Як зазначається в коментарі, http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx може бути корисним і може працювати, але це концептуально складніше, ніж намагатися керувати ролями безпосередньо.

— Кріс Траверс
джерело