Управление пользователями в ПО на основе СУБД Interbase (FireBird)

© 2003 Лагунов Алексей

Для управления правами доступа к данным системы используются встроенные средства SQL сервера Interbase/FireBird и дополнительно собственные настройки, которые хранятся в таблицах системы.

Для заведения пользователя необходимо завести соответствующий логин (пользователя) на SQL сервере, эта операция может выполнятся как средствами разрабатываемой системы так и сторонними программными продуктами. Эту операцию выполняет системный администратор сервера от имени пользователя SYSDBA.

В БД системы существует ряд таблиц, содержащих информацию о правах доступа пользователя, на основе этих таблиц созданы представления для управления подключения пользователя в систему.

Разграничение на доступ к данным осуществляется на основе ролей – встроенного средства SQL сервера Interbase(FireBird) – прототипов доступа к данным. Роль – это определённая категория пользователей, исполняющих определённые функциональные обязанности. В данный момент заведено две роли: администратор и сотрудник товарного отдела

• Роли администратор разрешён доступ ко всем таблицам в режиме чтение/запись/удаление
• Роли сотрудника товарного отдела разрешён доступ в режиме только чтения к справочникам и в режиме чтение/запись/удаление к таблице документов и проводок.

Основная таблица отвечающая за раздачу прав – это access_users. В ней содержится информация о пользователях, которым непосредственно разрешён доступ в систему. Также для каждого пользователя указывается роль, под которой ему необходимо производить подключение к базе данных.

На основе этой таблицы созданы два представления V_USER_ROLES – это представление служит для определения роли текущего пользователя в момент подключения к БД и представление V_ACCESS_USERS – служит для определения прав доступа к модулям и режимам программного комплекса. Эти представления замечательны тем, что содержат только данные подключившегося пользователя (это достигается использованием в запросе, на основание которого сформированы эти представления, системной переменной user).

На представление V_USER_ROLES дано право на чтение для встроенного пользователя SQL сервера PUBLIC – с правами данного пользователя происходит подключение к БД любого другого пользователя, которому не даны явные права на доступ к БД или не даны права через роль при подключении.

Подключение к БД происходит в два этапа – на первом этапе происходит подключение как обычного пользователя, без указания роли подключения и производится попытка считать данные из представления V_USER_ROLES – в случае получения оттуда данных значит, что пользователь производящий подключение зарегистрирован в БД системы и производится чтение роли подключения данного пользователя из указанного выше представления. После этого отключаемся от БД и производим повторное подключение к БД но уже с указанием роли пользователя, полученной на первом этапе.

После успешного подключения читаем права доступа на модули и режимы из представления V_ACCESS_USERS. После этого система готова к работе.

Доступ к таблице access_usersимеют только администраторы. Данные в неё вносятся через соответствующий режим.

Режим добавления нового пользователя

Добавить пользователя, изменить ему роль имеет право только главный администратор, т.е. администратор – владелец БД. В терминах SQL сервера Interbase (FireBird) это пользователь, от чьего имени создана БД и (или) пользователь SYSDBA. Все остальные администраторы могут изменять права доступа внутри приложения.

Изменение пароля пользователя

Изменить пароля пользователя, работающего в программе, можно только при участии администратора SQL сервера Interbase (FireBird) - это особенность архитектуры (возможно есть всё же другой метод - но кроме как напрямую писать в ISC4.GDB я не знаю - а это не есть хорошо).

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

Ниже даны скрипты на создание соответствующих таблиц и представлений.

/******************* Представление V_USER_ROLES *********************/

CREATE VIEW 
    V_USER_ROLES (
       USER_NAME, ROLE_NAME
                                  )
AS 
    SELECT 
        access_users.access_user_name, 
        access_users.ROLE_NAME 
    FROM 
        access_users 
    WHERE 
           (access_users.access_forbidden = 0) 
       and 
           (access_users.access_user_name = user);

/******************* Представление V_USER_ROLES *********************/
Представление содержит права доступа в программе для работающего пользователя. Штатно в этом представлении содержится одна запись.

CREATE VIEW V_ACCESS_USERS (
    SPR_PEOPLE_FAM,
    SPR_PEOPLE_NAME,
    SPR_PEOPLE_SNAME,
    SHORT_FIO,
    ACCESS_USER_NAME,
    SPR_PEOPLE_ID,
    ACCESS_FORBIDDEN,
    ROLE_NAME,
    EDIT_RASHOD,
    EDIT_PRIHOD,
    EDIT_SPR_TOBAR,
    EDIT_SPR_CLIENT,
    EDIT_SPR_SUPER,
    EDIT_SPR_BANK,
    EDIT_PRICE,
    EDIT_MOVE,
    SEE_SPR_CLIENT,
    SEE_SPR_TOBAR,
    EDIT_SPR_SKLAD,
    NASTR_TODAY,
    DEL_SPR_TOBAR,
    SEE_USER_ADMIN,
    EDIT_USER_ADMIN,
    DEL_USER_ADMIN,
    AU_REVERT_RASH_OTGR_DOC)
AS
SELECT
    spr_people.spr_people_fam,
    spr_people.spr_people_name,
    spr_people.spr_people_sname,
    spr_people.short_fio,
    ACCESS_USERS.ACCESS_USER_NAME,
    ACCESS_USERS.SPR_PEOPLE_ID,
    ACCESS_USERS.ACCESS_FORBIDDEN,
    ACCESS_USERS.ROLE_NAME,
    ACCESS_USERS.EDIT_RASHOD,
    ACCESS_USERS.EDIT_PRIHOD,
    ACCESS_USERS.EDIT_SPR_TOBAR,
    ACCESS_USERS.EDIT_SPR_CLIENT,
    ACCESS_USERS.EDIT_SPR_SUPER,
    ACCESS_USERS.EDIT_SPR_BANK,
    ACCESS_USERS.EDIT_PRICE,
    ACCESS_USERS.EDIT_MOVE,
    ACCESS_USERS.SEE_SPR_CLIENT,
    ACCESS_USERS.SEE_SPR_TOBAR,
    ACCESS_USERS.EDIT_SPR_SKLAD,
    ACCESS_USERS.NASTR_TODAY,
    ACCESS_USERS.DEL_SPR_TOBAR,
    ACCESS_USERS.SEE_USER_ADMIN,
    ACCESS_USERS.EDIT_USER_ADMIN,
    ACCESS_USERS.DEL_USER_ADMIN,
    ACCESS_USERS.au_revert_rash_otgr_doc
FROM
    ACCESS_USERS,
    spr_people
WHERE
    spr_people.spr_people_id = ACCESS_USERS.spr_people_id and
    ACCESS_USERS.ACCESS_USER_NAME = user;

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

/******************* Представление V_REGISTRED_USERS *********************/
Данное представление содержит всех пользователей зарегестрированных в системе и их роли

CREATE VIEW V_REGISTRED_USERS (
    USER_NAME,
    ROLE_NAME,
    SPR_PEOPLE_FAM,
    SPR_PEOPLE_NAME,
    SPR_PEOPLE_SNAME,
    SHORT_FIO)
AS
SELECT RDB$USER_PRIVILEGES.RDB$USER,
    RDB$ROLES.RDB$ROLE_NAME,
    SPR_PEOPLE.SPR_PEOPLE_FAM,
    SPR_PEOPLE.SPR_PEOPLE_NAME,
    SPR_PEOPLE.SPR_PEOPLE_SNAME,
    SPR_PEOPLE.SHORT_FIO
FROM SPR_PEOPLE
    RIGHT OUTER JOIN ACCESS_USERS ON (SPR_PEOPLE.SPR_PEOPLE_ID = ACCESS_USERS.SPR_PEOPLE_ID)
    INNER JOIN RDB$USER_PRIVILEGES ON (ACCESS_USERS.ACCESS_USER_NAME = RDB$USER_PRIVILEGES.RDB$USER),
    RDB$ROLES
WHERE
    (
        (RDB$ROLES.RDB$ROLE_NAME = RDB$USER_PRIVILEGES.RDB$RELATION_NAME)
    );

Описанная выше технология накладывает ограничение на подключение пользователя к БД: каждый логин пользователь может работать в комплексе только от имени одной роли, хотя сама СУБД Interbase/FireBird не содержит этого ограничения.

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

Таким образом технологию можно развивать в зависимости от требований конкретной задачи.

P.S. Всё выше изложенное - это мои личные наработки и наблюдения. Жду предложений и пожеланий по поводу написанного.

Copyright© 2003 Лагунов Алексей  Специально для Delphi Plus