Авторизация и роли — по шагам

Это самый сложный урок паттерна — и самый важный. Разберём вход и роли по шагам, чтобы не запутаться. Не спеши: пройди шаги по очереди, и всё сложится. Всё соберёт Claude Code, а твоя задача — понимать, что происходит.

🎯 После урока сможешь: настроить вход по логину и роли пользователей по шагам.

Шаг 1. Регистрация и пароль

Пользователь заводит логин и пароль. Пароль никогда не хранят как есть. Его превращают в нечитаемый отпечаток (хеш) специальным способом (bcrypt). Даже если база утечёт, пароли из неё не достать.

Правило: пароли — только в виде хеша (bcrypt), не открытым текстом. Это как секреты в .env: то, что нельзя показывать, не хранят в читаемом виде.

Шаг 2. Вход (логин)

При входе пользователь вводит логин и пароль. Система берёт введённый пароль, превращает в хеш тем же способом и сравнивает с сохранённым. Совпало — впускаем.

Страница входа в CRM: поля email и пароль, кнопка «Войти».

Шаг 3. Пропуск: сессия или JWT

После входа система выдаёт пользователю «пропуск», чтобы не спрашивать логин на каждой странице. Пропуск бывает двух видов — сессия (метка на сервере) или JWT (подписанный токен у пользователя). Для начала подойдёт любой; Claude Code настроит один из них.

Шаг 4. Проверка роли

У каждого пользователя есть роль (админ / менеджер / просмотр). Перед каждым важным действием система проверяет: «а можно ли этой роли?». Админ видит всё, менеджер — только своих клиентов, просмотр — только читает.

Проверка роли: заходит пользователь, система проверяет роль и показывает только разрешённое — админ видит все заявки с кнопками изменить/удалить, менеджер видит свои заявки с кнопкой изменить, просмотр видит все заявки без кнопок изменения.
Два экрана рядом: вид администратора (все заявки, кнопки изменить и удалить) и вид менеджера (только свои заявки, без кнопки удалить).

Контрольный вопрос. Как правильно хранить пароли пользователей?

АОткрытым текстом в базе — так проще сверять при входе
БТолько в виде хеша (bcrypt), а не открытым текстом
ВВ файле .env рядом с токенами, туда никто не заглядывает

Подсказка: Даже если база утечёт, пароли из неё не должны достаться.

Онлайн-проверка ответа появится позже

Контрольный вопрос. Зачем после входа выдают «пропуск» (сессию или JWT)?

АЧтобы держать пароль под рукой и сверять его при каждом клике
БЧтобы разгрузить базу данных и ускорить запросы
ВЧтобы не спрашивать логин и пароль на каждой странице

Подсказка: Пропуск подтверждает, что пользователь уже вошёл.

Онлайн-проверка ответа появится позже

Контрольный вопрос. Менеджер зашёл в CRM. Что он НЕ должен мочь по правилам ролей?

АМенять статус и комментарий в своей заявке
БВидеть заявки своих клиентов и их контакты
ВВидеть чужих клиентов и удалять данные

Подсказка: Вспомни таблицу ролей: у менеджера прав меньше, чем у админа.

Онлайн-проверка ответа появится позже

Контрольный вопрос. Представь, что Claude Code проверяет роль пользователя ДО входа по логину и паролю — ещё когда неизвестно, кто открыл страницу. Что не так с таким порядком шагов?

АВсё в порядке, роль можно проверить в любой момент
БРоль нельзя проверить, пока пользователь не вошёл — сначала логин и пароль, потом роль
ВНе так только то, что это медленнее — по смыслу порядок не важен

Подсказка: Роль хранится у конкретного пользователя — вспомни, на каком шаге система впервые узнаёт, кто перед ней.

Онлайн-проверка ответа появится позже

Что дальше

Ты прошёл самое сложное — вход и роли по шагам. В последнем содержательном уроке закроем безопасность (инъекции, XSS), миграции и деплой — и добавим мини-аналитику для руководителя.

← Назад  ·  ↑ В начало урока  ·  ⌂ В начало курса  ·  Вперёд →

Школа Виктора Комлева