Разграничение доступа к элементам формы в зависимости от роли в базе?

Question

[Radzhab]

Очень часто видел в программах авторизацию по ролям. Например Администратор, Бухгалтер, Начальник и т.д.
Как вообще организуется разграничение элементов на форме? Заходишь под админом- один интерфейс, под бухгалтером - другой.
Тупо делать ifUserAdmin then show button1, button2 не катит) Как профи делают это?

Answer 1

[brutal_lobster]

По поводу авторизации:
Фактически так и делается же) Только не if..then, а что-то вроде поиска (lookup) по таблице или списку прав доступа при осуществлении действия над конкретным объектом (отобразить кнопку, нажать на кнопку)
Обычно стоит вопрос - на каком уровне как хранить ACL и осуществлять проверку доступа.
Может быть это будет центральная матрица доступа или вообще атрибут объекта...

По поводу внешнего вида интерфейса:
Если интерфейс сложный и необходима детальная кастомизация - так и храните описание форм вместе с ролью, группой юзеров или в настройках самого юзера.

Comments

[Radzhab]

Спасибо за ответ) а нет ли какого нить туториала по данной тематике? гугл молчит

Answer 2

[cjey]

Наиболее простым вариантом будет хранить в таблице T_UserRights(ID_User, ID_Button, isVisible)
ID_Button в форме хранить в поле Tag.

Ну и потом

foreach(Control item in Controls)
{
  if (item is Button)
  {
    (Button)item.Visible = // берем значение из таблицы.
  }
}

Но права пользователей нужно проверять на уровне базы, нельзя доверять эту проверку клиенту (ее элементарно обойти).

Comments

[Radzhab]

Спасибо за ответ) а нет ли какого нить туториала по данной тематике? гугл молчит

[cjey]

К сожалению, хорошего тараторила посоветовать не могу. Для ограничения прав на уровне базы могу посоветовать гуглить в сторону "sql grant".

Answer 3

[Anatoliy Mikhailov]

Мы как-то в asp.net webforms на каждую таблицу и отдельные объекты со своей логикой давали отдельное уникальное название в таблице безопасности (назовем их rightsobject) + еще одна таблица отношений этих rightsobject с guid пользователя/роли и int правами (с побитовым указанием прав)

и в форме редактирования запускали хранимую процедуру которая возвращала права, и уже по ним велась логика может/не может

и в админ панели уже можно было гибко настроить кто что может делать.