Управление на потребители в софтуер, базиран на Interbase DBMS (FireBird)
Сайт на Delphi: ежедневни Delphi-новини, документация, статии, преглед, интервю, компютърен хумор.
Управление на потребители в софтуер, базиран на Interbase DBMS (FireBird)
За управление на правата за достъп до системните данни се използват вградените инструменти на Interbase/FireBird SQL сървъра и допълнително техните собствени настройки, които се съхраняват в системните таблици.
За да създадете потребител, трябва да създадете подходящ вход (потребител) на SQL сървъра, тази операция може да се извърши както чрез разработваната система, така и чрез софтуерни продукти на трети страни. Тази операция се извършва от системния администратор на сървъра от името на потребителя на SYSDBA.
В системната база данни има редица таблици, съдържащи информация за правата на достъп на потребителя, въз основа на тези таблици се създават изгледи за управление на връзката на потребителя към системата.
- На ролята на администратор е разрешен достъп до всички таблици в режим на четене/запис/изтриване
- В ролята на служител на стоковия отдел е разрешен достъп в режим само за четене до директории и в режим четене/запис/изтриване до таблицата с документи и осчетоводявания.
Основната таблица, отговорна за разпределянето на правата, еaccess_users. Съдържа информация за потребителите, на които е разрешен директен достъп до системата. Също така за всеки потребител е посочена ролята, под която трябва да се свърже с базата данни.
Въз основа на тази таблица се създават два изгледаV_USER_ROLES- този изглед се използва за определяне на ролята на текущия потребител в момента на свързване към базата данни, а изгледътV_ACCESS_USERSсе използва за определяне на правата за достъп до модули и режими на софтуерния пакет. Тези изгледи са забележителни с това, че съдържат само данните на свързанитепотребител (това се постига чрез използване на системната променливаuserв заявката, на която се основават тези изгледи).
ИзгледътV_USER_ROLESима право на четене за потребителя на вградения SQL сървърPUBLIC– с правата на този потребител всеки друг потребител е свързан към базата данни, на който не са дадени изрични права за достъп до базата данни или не са му дадени права чрез ролята при свързване.
Свързването към базата данни става на два етапа - на първия етап се осъществява връзка като нормален потребител, без да се посочва ролята на връзката, и се прави опит за четене на данни от изгледаV_USER_ROLES- ако се получат данни от там, това означава, че потребителят, който прави връзката, е регистриран в системната база данни и ролята на връзката на този потребител се чете от горния изглед. След това прекъсваме връзката с базата данни и се свързваме отново с базата данни, но с посочване на потребителската роля, получена на първия етап.
След успешно свързване четем правата за достъп до модули и режими от изгледаV_ACCESS_USERS. След това системата е готова за работа.
Само администратори имат достъп до таблицатаaccess_users. Данните се въвеждат в него чрез съответния режим.
Добавете нов потребителски режимСамо главният администратор има право да добавя потребител, да променя ролята му, т.е. администраторът е собственик на базата данни. По отношение на Interbase SQL сървъра (FireBird), това е потребителят, от чието име е създадена базата данни и (или) потребителят на SYSDBA. Всички други администратори могат да променят правата за достъп в приложението.
Промяна на потребителската паролаМожете да промените паролата на потребител, работещ в програмата, само когатоучастието на администратора на Interbase SQL сървъра (FireBird) е характеристика на архитектурата (може би все още има друг метод - но не знам друг освен как директно да пиша в ISC4.GDB - и това не е добре).
Процесът на промяна на паролата е както следва: потребителят, който трябва да промени паролата, извиква режима за промяна на паролата, въвежда старата парола, новата. След това администраторът потвърждава въведените от потребителя данни с неговата парола - и ако всичко е правилно, паролата се променя.
По-долу са скриптовете за създаване на съответните таблици и изгледи.
CREATE VIEWV_USER_ROLES ( USER_NAME, ROLE_NAME )AS SELECTaccess_users.access_user_name, access_users.ROLE_NAMEFROMaccess_usersWHERE(ac cess_users.access_forbidden = 0)и(access_users.access_user_name = потребител);
/************************ Изглед V_USER_ROLES *********************/ Изгледът съдържа правата за достъп в програмата за работещия потребител. Обикновено този изглед съдържа един запис.
СЪЗДАВАНЕ НА ИЗГЛЕДV_ACCESS_USERS ( SPR_PEOPLE_FAM, SPR_PEOPLE_NAME, SPR_PEOPLE_SNAME, SHORT_FIO, ACCESS_USER_NAME, SPR_PEOPLE_ID, ACCESS_FORBIDDEN, ROLE_ NAME, <1 1>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)ASSELECTspr_pe ople.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_C LIENT, 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_docFROMACCESS_USERS, spr_peopleWHEREspr_people.spr_people_id = ACCESS_USERS.spr_people_idиACCESS_USERS.ACCESS_USER_NAME =потребител;
Също така привеждам спомагателното представяне, с помощта на което се извършва допълнително управление на потребителите в системата.
/******************** Представление V_REGISTRED_USERS *********************/ Данното представяне съдържа всички потребители, регистрирани в системата и техните роли
СЪЗДАВАНЕ НА ИЗГЛЕДV_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_FIOОТSPR_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$ РОЛИWHERE( (RDB$ROLES.RDB$ROLE_NAME = RDB$USER_PRIVILEGES.RDB$RELATION_NAME) );
Технологията, описана по-горе, налага ограничение върху връзката на потребителя с базата данни: всеки регистриран потребител може да работи в комплекса само от името на една роля, въпреки че самата СУБД Interbase/FireBird не съдържа това ограничение.
Така технологията може да се развива в зависимост от изискванията на конкретна задача.
P.S. Всичко по-горе е мой личен опит и наблюдения. Очаквам предложения и пожелания относно написаното.