Управління користувачами на базі СУБД Interbase (FireBird)

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Управління користувачами на базі СУБД Interbase (FireBird)

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

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

У БД системи існує ряд таблиць, що містять інформацію про права доступу користувача, на основі цих таблиць створені уявлення для керування підключення користувача до системи.

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

Основна таблиця, що відповідає за роздачу прав – це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 я не знаю - а це не є добре).

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

Нижче наведено скрипти на створення відповідних таблиць та уявлень.

CREATE VIEWV_USER_ROLES ( USER_NAME, ROLE_NAME )AS SELECTaccess_users.access_user_name, access_users.ROLE_NAMEFROMaccess_usersWHERE(access_users.access_forbidden = 0)and(access_users. access_user_name = user);

/******************* Подання V_USER_ROLES *********************/ Подання містить права доступу до програми для працюючого користувача. Штатно в цьому поданні міститься один запис.

CREATE VIEWV_ACCESS_USERS ( SPR_PEOPLE_FAM, SPR_PEOPLE_NAME, SPR_PEOPLE_SNAME, SHORT_FIO, ACCESS_USER_NAME, SPR_PEOPLE_ID, SPR_PEOPLE_NAME, EDIT_RASHOD, EDIT_PRIHOD, EDIT_SPR_TOBAR, EDIT_SPR_CLIENT, EDIT_SPR_SUPER, EDIT_SPR_BANK, EDIT_PRICE, EDIT_MOVE, AR, EDIT_SPR_SKLAD, NASTR_TODAY, DEL_SPR_TOBAR, SEE_USER_ADMIN, EDIT_USER_ADMIN, DEL_USER_ADMIN, AU_REVERT_RASH_OTGR_DOC<<>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, ACC ESS_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_docFROMACCESS_USERS, spr_peopleWHEREspr_people.spr_people_id = ACCESS_USERS.spr_people_idіACCESS_USERS.ACCESS_USER_NAME =користувач;

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

/******************** Представлення V_REGISTRED_USERS *********************/ Дане представлення містить всіх користувачів, зареєстрованих в системі та їх роликах

CREATE VIEWV_REGISTRED_USERS ( USER_NAME, ROLE_NAME, SPR_PEOPLE_FAM, SPR_PEOPLE_NAME, SPR_PEOPLE_SNAME, SHORT_FIO)AS SELECTRDB$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_FIOFROMSPR_PEOPLERIGHT OUTER JOINACCESS_USERSON(SPR_PEOPLE.SPR_PEOPLE_ID = ACCESS_USERS.SPR_PEOPLE_ID)INNER JOINRDB$USER_PRIVILEGESON(ACCESS_USERS.ACCESS_USER_NAME = RDB$USER_PRIVILEGES.RDB$USER), RDB$ROLESWHERE( (RDB$ROLES.RDB$ROLE_NAME = RDB$USER_PRIVILEGES.RDB$RELATION_NAME) );

Описана технологія накладає обмеження на підключення користувача до БД: кожен логін користувач може працювати в комплексі тільки від імені однієї ролі, хоча сама СУБД Interbase/FireBird не містить цього обмеження.

Таким чином, технологію можна розвивати в залежності від вимог конкретного завдання.

P.S. Все вище викладене – це мої особисті напрацювання та спостереження. Чекаю на пропозиції та побажання з приводу написаного.