ДОВІДНИК З NODE-RED українською мовою
У даному розділі описується шаблон для платформи UBOS який дає вам можливість швидко почати розробляти застосунки, що потребують автентифікації користувача (перевірка автентичності) та його авторизації (дозволи в системі).
Порядок створення такого застосунку описано в даній статті від Olha Mashtaler. Тут ми зупинимося на послідовному розкриванні принципів та організації роботи шаблону починаючи від бачення з точки зору користувача до аналізу коду кінцевої реалізації. Слід звернути увагу що на момент прочитання даного розділу, реалізація може бути вдосконаленою і мати інший код. Даний розділ може стати корисним як розробникам на базі платформи UBOS так і розробникам в Node-RED та Appsmith які становлять основу платформи.
Якщо Ви хочете ознайомитися з шаблоном по порядку викладення матеріалу - читайте далі. Якщо Вам необхідна довідка, можете перейти до наступних підрозділів:
Модуль передбачає організацію автентифікації користувачів на базі логіна (адреса електронної пошти) і пароля та надання їм доступу до дозволених сторінок користувацького інтерфейсу (UI, User Interface). Для початку варто зупинитися на організації такого доступу з точки зору використання застосунку. У цій частині ми не будемо розглядати як функціонує шаблон, а більше як ним користуватися адміністраторам та користувачам.
Користувацький інтерфейс розроблений на базі сторінок (page). Користувачу (user) надається доступ до кожної сторінки, та до її елементів, в залежності від того, до якої групи користувачів він належить. Для групування користувачів використовується рольова ієрархія. Роль (role) в даному шаблоні - це група користувачів, які мають однакові права щодо доступу до певних сторінок. Таким чином, усі користувачі які мають однакові ролі мають доступ до тих самих сторінок, і тих самих ементів на них. Розмежування доступу до контенту в межах сторінок в залежності від конкретного користувача не входить в даний шаблон, але він дає основу для такої реалізації і буде описаний в окремому розділі або статті.
Є особлива адміністраторська роль, яка має привілейований доступ, а саме до адміністративних сторінок. Особливість також в тому, що ця роль так як і перший користувач з цією роллю створюється в режимі розроблення а не функціонування розгорнутого застосунку. Тому напочатку адміністратор системи є розробником розгорнутого застосунку, хоча пізніше цього користувача можна буде видалити.
Сторінки інтерфейсу можуть бути доступним всім, або конкретній ролі. За замовченням в профілі налаштовані наступні сторінки з шаблону:
При створенні профілю адміністратора йому необхідно надати доступ до таких сторінок шаблону:
Модуль (Module) - це посилання на сторінку або групу сторінок. Модулі організовують двухрівневе меню: перший рівень - батьківські модулі, другий - дочірні (рис.1). Таким чином модулі можна вважати пунктами меню, а організація доступу до сторінок зводиться до організації меню сторінок для кожного користувача. Так наприклад у адміністратора системи меню має принаймні один батьківський модуль, куди включені три дочірні модулі - сторінки адміністрування.
рис.1. Організація меню через модулі
Батьківські модулі можуть бути посиланнями на сторінку або вміщувати дочірні модулі (вкладені пункти меню). Дочірні модулі - є посиланнями на сторінки. У плинній версії шаблону назва модулю що посилається на сторінку має співпадати з назвою сторінки в редакторі. Також є обмеження щодо назви сторінок, вони не повинні бути кирилицею та містити пробіли.
Модулі налаштовуються на сторінці шаблону Modules (рис.2), який доступний тільки користувачам з адміністративною роллю. Там можна створювати та редагувати модулі та організовувати порядок відображення їх в меню.
рис.2. Сторінка Modules
Як вже зазначалося, роль - це група користувачів, яким надаються однакові права щодо доступу до сторінок. Ролі створюються та редагуються на сторінці AdminRoles (рис.3). Так у ролі “Admin” є доступ до батьківського модуля Management
, який включає три дочірні модулі доступу до адміністративних сторінок.
рис.3. Сторінка AdminRoles
На сторінці AdminRoles кожній ролі можна надати певні дозволи Permissions
, до модулів з вказаними опціями (рис.4). Обмеження по опціям не є частиною шаблону їх можна реалізовувати розробнику самостійно.
рис.4. Надання дозволів ролям (Add Permissions To Role
)
Користувачі можуть реєструватися самі в системі, або створюватися адміністратором. У будь якому випадку усіх користувачів та їх налаштування (окрім паролю) видно на адміністративній сторінці UserManagement (рис.5).
рис.5. Сторінка UserManagement
На цій сторінці також можна видаляти існуючих або добавляти нових користувачів. Варто зауважити, що видалені користувачі по факту не видаляються з бази даних, вони помічаються як видалені. Натиснувши “Create User” адміністратор системи може добавляти користувача та надавати йому усі необхідні налаштування (рис.6). При цьому, на відміну від самостійної реєстрації, підтвердження актуальності адреси пошти не потрібно.
рис.6. Сторінка створення користувача
Користувач що бажає зареєструватися повинен зайти на сторінку “Registration” заповнити свої дані та натиснути “Signup”.
рис.7. Сторінка самостійної реєстрації користувача користувача
Після цього висвітиться інформаційна сторінка (рис.8) а на пошту буде відправлено листа (рис.9).
рис.8. Інформаційна сторінка про відправлення на пошту листа для підтвердження пошти.
рис.9. Лист на пошті.
Натиснення “Confirm” підтвердить справжність пошти і користувачу буде запропоновано зайти в систему через сторінку входу (рис.10).
рис.10. Сторінка входу користувача.
У цій частині розділу ми розглянули функціонування авторизаційного модуля з точки зору користувачів. Далі розглянемо реалізацію модуля в серверній та клієнтській частині.
Далі буде.