|
|
|
Права доступа на хранимые процедуры и видимость контролов, их вызывающих
|
|||
|---|---|---|---|
|
#18+
В mssql заведены логины пользователей. На сервере есть набор хранимых процедур, которые вызываются через контролы в приложении, например, TButton. Как сделать права доступа, чтобы пользователи могли вызывать и видеть только разрешённые им кнопки/процедуры? Какие есть best practices , чтобы хранить права единожды, желательно через пользователей/роли mssql? Пока придумал велосипед: 1) к TButton добавляем свойство ActionDataset подобно этому методу ; 2) указываем в TButton.ActionDataset ту T*StoredProc, при наличии прав на которую- кнопка видима; 3) если в TButton.OnClick вызывается несколько T*StoredProc, то выбираем одну с подходящими правами; 4) раздаём права на процедуры стандартным образом в mssql; 5) получаем от mssql список прав на процедуры, например, при старте приложения или при показе формы, если права могут часто меняться; 6) при показе формы с TButton или в TAction.OnUpdate устанавливаем их видимость согласно наличию в 5) хранимой процедуры из TButton.ActionDataset плюсы- используются стандартные mssql права и источник прав можно указать в дизайнере; минусы- за содержимым TButton.OnClick нужно следить, т.к. можно вызвать не ту T*StoredProc, что указана в TButton.ActionDataset. PS не дизассемблировать же содержимое TButton.OnClick ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2017, 23:50:47 |
|
||
|
Права доступа на хранимые процедуры и видимость контролов, их вызывающих
|
|||
|---|---|---|---|
|
#18+
Я бы не привязывал жестко права на ГУИ и ХП. В некот. случаях одна ХП может служить многим задачам. Каждый контрол/поле грида должен иметь соответствие на некий "источник прав", не обязательно соответствующий правам мсскл. Этим источником удобно делать поля датасета. В шапке документа, в строках грида и т.д. Поле строчное или целое. Тогда нужный бит или символ соотв. нужным правам. При желании можно все уложить в одну таблицу с правами, кот. удобно зачитывать и настраивать. Возможность раздачи прав на мсскл объекты при желании также можно там предусмотреть. Пусть не на все, но на ключевые. Как ни крути, хранить единожды не получится из-за самой природы прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 10:00:31 |
|
||
|
Права доступа на хранимые процедуры и видимость контролов, их вызывающих
|
|||
|---|---|---|---|
|
#18+
Я бы вообще не заморачивался изменением в интерфейсе зависимостью от прав в SQL сервере. Ну обработайте красиво ошибку отсутствия пермишенов, делов то. Ткнет пользователь в кнопку, получит сообщение об отсутствии прав, в следующий раз просто не будет кликать, обломается :) А для упрощения работы себе я бы добавил в это окно кнопку запроса прав и если пользователю по ошибке не хватает прав то он нажимает эту кнопочку, вам поступает сообщение о запросе прав, подтверждаете и вуаля, права выданы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 10:07:19 |
|
||
|
Права доступа на хранимые процедуры и видимость контролов, их вызывающих
|
|||
|---|---|---|---|
|
#18+
LSVВ некот. случаях одна ХП может служить многим задачам.Если такой подход, то можно выкрутиться через несколько T*StoredProc с одинаковым именем. эндиЯ бы вообще не заморачивался изменением в интерфейсе зависимостью от прав в SQL сервере. Иногда бизнес диктует условия. эндиТкнет пользователь в кнопку, получит сообщение об отсутствии прав, в следующий раз просто не будет кликать, обломается :) Так и есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 20:31:26 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39476997&tid=2042105]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
233ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 569ms |

| 0 / 0 |
