@DIASTAH

Как реализовать разграничение прав доступа в Delphi?

База данных на Delphi. Требуется сделать разграничение прав доступа: обычного пользователя и администратора. На данный момент моя программа выглядит так: при запуске появляется форма авторизации, а затем уже открывается сама программа и можно пользоваться всеми её возможностями. Логин и пароль хранятся в коде программы. Как реализовать это разграничение доступа?
  • Вопрос задан
  • 84 просмотра
Пригласить эксперта
Ответы на вопрос 3
HemulGM
@HemulGM
Delphi Developer, сис. админ
Для курсового проекта достаточно добавить поле в таблицу пользователей, обозначающее права админа.
Грубо говоря - IS_ADMIN (INT).
После входа читаешь это значение и в зависимости от него просто не позволяешь выполнять некоторые функции. Либо скрываешь кнопки и пункты меню, либо просто при выполнении проверяешь, есть ли флаг IS_ADMIN у авторизованного пользователя и в противном случае выдаешь ошибку и прерываешь выполнение функции.

Это простой пример для понимания. Его достаточно для курсового проекта. Нормальную систему ролей делать хлопотно и зачастую для этого требуется бэкенд, реализующий API для доступа к БД.
Ответ написан
Zoominger
@Zoominger
System Engineer
Создайте переменную "роль" и привяжите её к пользователю.
Создайте две роли - админ и юзер и проверяйте роль во всех функциях, которые используются в таблице и доступную функциональность определяйте в зависимости от роли.
На таблицы тоже сделайте признаки, которые будут определять возможность записи в зависимости от роли (тут просто сравнение "админ" и "текущая роль пользователя").

Достаточно понятно? Я немного упростил. Можно было бы проработать роли, сделав возможность их настраивать вплоть до отдельных таблиц и функций, но это гораздо сложнее.
Ответ написан
@acwartz
angular, hello world java, chrome ext/, delphi
Нужно думать не о ролях а о привилегиях. Право на чтение таблицы или таблиц (SELECT) право на редактирование (UPDATE) право на удаление (DELETE). А роли это уже косметика которая иерархично выстраивает привилегии.
Исходя из выданных привилегий сами решаете что есть админ т.к. ими же (привилегиями) можете проверять экклюзивный доступ требующий привилегии ADMIN_ACCESS например. Таким образом админ тот у кого есть ADMIN_ACCESS привилегия.

Проще говоря есть некий код, который по логину-пароль возвращает интерфейс IUser у которого есть дочерний объект-интерфейс IRights у которого есть функция HavePrivilege(PriviligeID, ISecurityContext) где PriviligeID некое числовое или строковое обозначение привилегии (которая захардкожена в коде и используется где нужно),
ISecurityContext - интерфейс на список данных доступ к которым проверяется, это может быть что угодно:
- имя таблицы
- имя компонента
и .т.д.

Допустим Вы проектируете форму кредитных заявок, есть 2 роли:
- администратор, который видит все заявки в системе, от всех операторов и может их удалять.
- операционист, который их создает, редактирует и видит только те заявки, которые создал сам.

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

Собственно у вас 2 формы:
- 1. Форма с таблицей заявок.
- 2. Форма заявки.

Логика такая:
Открывается форма-список заявлений, проверяется разрешение TABLE_READ, если его нет - отлуп с сообщением "У вас нет прав на просмотр этих данных". Юзер видит пустой грид и кнопку закрыть.
Если TABLE_READ есть, и среди указанных там таблиц НЕТ "CreditRequests", то тот же отлуп с сообщением.
Если TABLE_READ есть к этой таблице или это супер-привилегия чтения всех таблиц, то смотрим на фильтр, и применяем его к формируемому SELECT. Что такое фильтр?
В таблице CreditRequests есть поле OperID которая указывает на IUser.ID т.е. связывает запись с её создателем, таким образом через привилегию открытия таблицы с указанием фильтра, вы покажете юзеру только записи которые делал он сам.
Дальше открывается БД, с формированием выборки и отображением в грид.

Дальше на форме лежит какой-нибудь ActionList , где на вставку, редактирование и удаление записей идет проверка TABLE_EDIT, TABLE_DELETE схожим образом, т.е. если IUser.IRights отвечает что тип нет такого или нет для запрашиваемого объекта то отлуп с сообщением о нехватке прав.

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

Эта система прав сложна и обычно глубоко интегрируется в частности в компоненты отображения т.к. например оператор видит колонки (поля) записи таблицы, а администратор должен видеть и иметь возможность фильтровать данные в разрезе операторов которые заявки плодят, т.е. есть колонка которая из БД поднимает ФИО того кто заявку создал + можно сформировать лог изменений по заявке (кто и когда чего наизменял), сюда же встраивается механизм верификации т.е. оператор создал, админ принял/отказал, оператору вернулась заявка на доработку.
А то и ещё глубже идет разграничение, например разрешается редактировать только некоторые компоненты на форме (например ставить отметки/галочки или писать примечания).
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы