Kraysent
commented
4 months ago Пока идея следующая:
- В таблице пользователей делаем новые поля:
role,salt,password_hash, храним там соответствующие значения - Делаем таблицу токенов с полями -
token,user_id,expiry_time,active - Делаем метод
POST /api/v1/login, который принимает тело с логином и паролем и возвращает токен - случайный набор символов длинной около 30-40 символов. Он оказывается записан в БД с каким-то дефолтным expiry_time - по умолчанию что-то вроде 30 дней, наверное. - Далее все администраторские методы принимают заголовок
Authorization: Bearer <token>, каждый раз проверяя токен на живость и в случае отсутствия таковой отдавать код 401.
Список пользователей в production-окружении будет руками вставлен в базу, регистрации пользователей пока не предусматриваем.
Это поведение должно быть отключаемо в конфигурационном файле, чтобы не мучаться при локальном тестировании с логином.
В каждом методе API в таком случае перечислим список ролей, которым разрешён доступ до данного метода.
Итого flow вызова администраторских методов следующий:
- Если список
ALLOWED_ROLESметода пустой, пропустить пользователя и не делать ничего перечисленного ниже. - Проверить наличие заголовка с токеном, в случае отсутствия 401, ошибка - token is not present (это можно ещё на слое презентации делать).
- (на слое логики) проверить валидность токена, сходив в базу. Если его нет, или он уже expired, или он active=false, то 401 с одинаковой ошибкой - unauthorized.
- получить user_id и роли, соответствующие токену.
- убедиться, что роль находится в списке разрешённых в методе ролей (
ALLOWED_ROLES), если нет - 401, user does not have permission to use this method.
Для унификации и изоляции ответственности стоит сделать класс Authenticator (над названием подумать), который будет при старте программы подключаться к бд и будет уметь делать всё перечисленное выше. В итоге в бизнес-логике хочется только вызывать
user_id, role = authenticator.authenticate(token)и больше ничего не делать, Authenticator должен попадать через инъекцию зависимостей внутрь Actions, примерно в этот же момент хочется уметь манипулировать его активностью флагом в конфиге. Можно сделать красиво и сделать Authenticator интерфейсов с двумя реализациями - PostgresAuthenticator, который будет по-настоящему ходить в БД и разбираться с токенами, и NopAuthenticator, который будет в соответствующем методе ничего не делать. Тогда если флаг включения аутентификации включен, внедряем PostgresAuthenticator, если нет - NopAuthenticator.
Сейчас по поводу пользователей есть очень базовая таблица users. Нужно продумать процесс регистрации и проверки пользователей для того чтобы ограничить список людей, которые могут редактировать данные.
Предположение - нужно будет добавить столбец role в таблицу пользователей и руками проставить admin, по дефолту reader или что-то такое. В иделае это проверять бы на уровне nginx, но тут надо подумать.