https://flows.nodered.org/flow/5a0614db288deab2acb408d4bdcc9db0
Цей потік забезпечує «Авторизацію на основі файлів cookie» для кінцевих точок HTTP, які призначені лише для певних користувачів.
Цей потік є частиною набору node-red-authorization-examples, але також опублікований тут для полегшення пошуку
Попередні умови
Для цього прикладу потрібне таке розширення Node-RED:
- node-red-contrib-reusable-flows «Багаторазові потоки» дозволяють визначати декілька необхідних потоків один раз, а потім викликати їх із кількох місць
Крім того, він очікує, що глобальний контекст потоку міститиме об’єкт під назвою UserRegistry, який має такий же формат, як описано в ["node-red-within-express"](https://github.com/rozek/node-red- всередині експрес):
- імена властивостей об'єкта є ідентифікаторами зареєстрованих користувачів Ідентифікатори користувачів – це рядки без певного формату, це можуть бути імена користувачів, адреси електронної пошти або будь-які інші дані, які ви можете вибрати - за двома важливими винятками: ідентифікатори користувачів не повинні містити ні похилих рисок ("/"), ні будь-яких двокрапки (":") або описані нижче механізми автентифікації (і керування користувачами, описане в node-red-user-management-example )) не вийде. Крім того, верхній і нижній регістри в ідентифікаторах користувачів не розрізняються
- значення властивостей об'єкта є об'єктами JavaScript, щонайменше мають такі властивості (додаткові властивості можна додавати за бажанням):
- Roles або відсутній, або містить список рядків із ролями користувача. Немає спеціального формату для імен ролей, за винятком того, що ім’я ролі не повинно містити пробілів
- Salt це рядок, що містить випадкове значення "salt", яке використовується під час обчислення хешу пароля PBKDF2
- Hash це рядок, що містить фактичний хеш PBKDF2 пароля користувача
У разі використання поза «node-red-within-express» наведені нижче потоки дозволяють завантажувати такий реєстр із зовнішнього файлу JSON під назвою registeredUsers.json (або створювати, якщо такого файлу не існує або існуючий файл неможливо завантажити) і повертається після змін:
Ці потоки вже є частиною цього прикладу, але їх можна видалити (або налаштувати), якщо вони не потрібні.
Для цілей тестування та налагодження також можна імпортувати такий потік, який при натисканні виводить поточний вміст реєстру користувачів на консоль налагодження Node-RED:
Цей потік також уже є частиною цього прикладу.
Колекція Postman
З метою тестування репозиторій GitHub для цього прикладу додатково містить колекцію Postman. з кількома заздалегідь визначеними запитами.
Популярний підхід полягає в тому, щоб дозволити користувачам ввійти в систему та створити маркери доступу, які потім використовуються як «куки» для зв’язку між браузером і сервером. Браузери автоматично прикріплюють такі файли cookie до кожного запиту, а маркери, що містяться, можуть бути розроблені так, щоб вони «закінчувалися» або видалялися після «виходу».
Маркер у цьому прикладі складається з ідентифікатора користувача та терміну дії. Хоча він зберігається у вигляді звичайного тексту (і, отже, може перевірятися клієнтом), його значення захищено «дайджестом повідомлення» — як наслідок, будь-яка спроба змінити маркер неминуче буде розпізнана та призведе до втрати авторизації . З іншого боку, будь-яка успішна перевірка токена автоматично оновлює цей токен, тому термін дії токенів фактично закінчується лише після певного часу бездіяльності.
Ключ, який використовується для створення дайджестів повідомлень, вибирається випадковим чином під час запуску сервера – тому перезапуск сервера автоматично призведе до втрати всіх активних маркерів.
Час життя токена можна налаштувати - за замовчуванням встановлено 2 хвилини.
Щоб «увійти», надішліть форму, що містить змінні UserId і Password, у правильну кінцеву точку (/cookie-auth у цьому прикладі).
Примітка: чинне законодавство часто вимагає, щоб користувачі були поінформовані про використання файлів cookie. Файл cookie, який тут використовується, вважається «технічно необхідним файлом cookie», який не можна заборонити, якщо очікується, що відвіданий сайт працюватиме, як передбачено.
Верхні результати використовуються для успішної автентифікації та входу в систему, нижні – для невдалих.
Якщо ви вимагаєте, щоб користувач, який автентифікувався, мав певну роль, ви можете встановити для msg.requiredRole цю роль перед тим, як викликати cookie auth або cookie login - інакше ролі користувачів не перевірятимуться.
Після успішної автентифікації msg.authenticatedUser містить ідентифікатор автентифікованого користувача, а msg.authorizedRoles містить (можливо, порожній) список із ролями цього користувача.
У наступному прикладі показано, як інтегрувати автентифікацію на основі файлів cookie в потоки Node-RED:
- надіслати POST-запит до вказаної точки входу, щоб увійти, а потім
- надіслати запит GET до тієї ж точки входу, щоб підтвердити цей вхід і отримати доступ до захищеного ресурсу
(Колекція Postman, згадана нижче, полегшує ці кроки.)
Надсилання запитів GET без попереднього входу (або після закінчення терміну дії маркера) має завершуватися помилкою з кодом статусу 401 (Неавторизовано)
Запит на вхід має містити або
- тіло типу "application/json" із серіалізацією JSON об'єкта, що містить принаймні властивості
UserIdіPassword, або - тіло типу "application/x-www-form-urlencoded" зі змінними форми
UserIdіPassword, щонайменше
Додаткові властивості об’єкта або змінні форми ігноруватимуться самою автентифікацією, але передадуться будь-яким наступним вузлам.
Успішний вхід, перевірка маркера та оновлення маркера завжди додають відповідний файл cookie у властивість cookies об'єкта msg, який, таким чином, автоматично стає частиною відповіді потоку.
Будь-яка помилка входу або перевірки маркера автоматично видаляє файл cookie маркера, що можна порівняти з виходом із системи.
Автоматичні тести
Репозиторій GitHub для цього прикладу також містить деякі потоки для автоматизованих тестів.