Внедряване на механизъм за диференциране на правата за достъп до администраторската част
В моята практика на уеб разработка много често се сблъсквах със ситуации, при които клиентите си поставят конкретна цел, а именно разделяне на части от администраторския панел по отношение на наличността на определени потребители. В същото време разработването на този модул беше извършено в контекста на разширяема система, т.е. с нефиксиран брой модули, до които е организиран достъп, и съответно неограничен брой потребители на системата.
Е, сама по себе си тази тема е доста тежка и изисква известно време за анализ и поставяне на проблема.
В контекста на тази статия ще проведем разработка в контекста на някаква абстрактна информационна система, със собствена инфраструктура и архитектура, докато тази система предоставя на потребителя възможността да разширява функционалността, т.е. да инсталира нови модули и съответно задайте права за достъп до тях на този или онзи потребител, регистриран като системен администратор.
Нека обсъдим от самото начало архитектурата на модулната система върху избраната от нас псевдосистема.
Всички модули са представени като вложки, свързани към основния документ (индекс-файл). Заявката за модул идва от низа на заявката QUERY_STRING и името на приставката се предава като аргумент на акта. В някакъв момент от индекса на файла този параметър се премахва и обработва. След това, ако потребителят има достатъчно права за достъп до модула в контекста на четене, се проверява съществуването на модула, посочен в низа на заявката, и ако той съществува, той е свързан с индексния файл.
Споменах „контекста на четене“ с причина, тъй като нашата система предполага съществуването на два контекста за работа със системата, а именно четене и писане. В същото време четенето предполага директен достъп до модула и до онези части от него, които не предполагат промени в структурата на данните в базата данни. Под записа се приема, че се правят директни промени в информацията, съхранявана в базата данни.
За да приложим този механизъм, ще проверим стойността на променливата на низа на заявката „do“, която се обработва в самия модул и носи информация за кой раздел на модула трябва да бъде предоставен достъп на потребителя.
Стойността на do ще бъде фиксирана, тази променлива ще вземе следните стойности:
- main - основната част на модула (налична в контекста на четене)
- config - раздел за конфигуриране на модула (наличен в контекста на запис)
- създаване - изпълнява някои действия за добавяне на информация към базата данни (налична в контекста на запис)
- изтриване - достъп до раздел, който предоставя възможност за изтриване на някаква информация в контекста на този модул (наличен в контекста на запис)
- редактиране - достъп за редактиране на информация в контекста на модула (наличен в контекста на публикацията)
Като цяло този списък може да бъде увеличен, докато всичко зависи само от мащаба на проекта и неговите нужди от функционалност.
Сега директно за модулите. В допълнение към физическото съществуване на определен модул в контекста на файловата система на проекта, модулът трябва да бъде добавен и към специална таблица на базата данни, която ще съдържа информация за всички съществуващи модули в системата. Добавянето и промяната на данните от тази таблица обикновено се извършва директно в контекста на модулите, т.е. по време на тяхното инсталиране в системата. Това обаче вече е задълбочаване на принципите за разглеждане на разширяеми системи, за които ще говорим друг път и следователно ще се ограничим до ръчно актуализиране и добавяне на данни за модулите.