Web API для тестового задания на ASP.NET

• Table Of Contents
• ТЗ
• Общее описание
• Уточнения по реализации:
  • Авторизация
  • Поле user_password сущности user
  • Первый Admin
  • Метаданные создания, обновления и удаления
  • Эндпоинты
• Локальный запуск
  • Учетные данные пользователя-администратора:

Задание реализовано с уточнениями, описанными ниже

• Реализован API на ASP.NET 6

• Реализована поддержка docker-compose (см. "Локальный запуск")

• API задокументирован с помощью Swagger

• Проект структурирован по принципам clean architecture

• Используется CQRS через MediatR

• В качестве ORM используется Entity Framework Core, в качестве СУБД PostgreSql

• Аутентификация реализована через JWT токены

• Используется Redis для хэширования

• Написаны модульные и интеграционные тесты

  • Модульные тесты с помощью xUnit и FluentAssertions
  • Интеграционные с помощью testcontainters (и respawn) (поэтому нужен докер для их прогонки)

• Авторизация реализована через JWT токены
• Методы связанные с авторизацией перенесены в AuthorizationController, а именно регистрация, аутентификация, обновление токенов и завершение сессий
• + Изменение логина и пароля, потому что была выделена отдельная сущность UserAccount (Аккаунт пользователя), которая содержит данные для авторизации
• Так как была реализована JWT авторизация, при проверке правил авторизации не проверяется активен ли авторизованный пользователь, так как подразумевается, что если токен актуален, то и пользователь активен. При попытке авторизации неактивного пользователя вылетает ошибка

• В сущности user столбец user_password был перенесен в user_account и разделён следующим образом: user_account_passwordHash и user_account_passwordSalt. Сделано это для того, чтобы хранить пароли в БД в захэшированном виде

• Самый первый админ в БД создается с логином = Admin, а пароль его конфигурируется (см. DbInitExecutor.cs)
• Дефолтный пароль "AdminPassword"
  Значение в docker-compose = "Admin" (см. Учетные данные администратора)

• Метаданные создания, обновления есть у всех сущностей, а метаданные удаления у сущностей поддерживающих мягкое удаление
• Так как в JWT Токене для валидности данных используются клеймы user_id и user_account_id. Было принято решение использовать Redis для хэширования логина по user_account_id для заполнения полей created_by, modified_by, revoked_by
• Однако все равно возникает проблема из-за метода изменение логина: в данном сценарии при изменении логина придется во всех сущностях искать и менять поля метаданных ..._by на новый логин. Это сложная операция и тут появляется проблема, которую нужно решить либо убиранием метода смены логина, либо сменой значений полей ..._by на user_account_id, а не login. Несмотря на сильные отклонения от ТЗ, этот момент я уже решил не менять и оставить как есть

• Создание пользователя — "/Authorization/SignUp"
• 6 и 7 эндпоинты по получению данных о пользователя были реализованы в одном эндпоинте из-за JWT авторизации

• git clone https://github.com/Skye7012/UserApiTestTask.git

• cd UserApiTestTask

• docker-compose build

• docker-compose up

• Swagger: http:https://localhost:5000/swagger/index.html

{
  "login": "Admin",
  "password": "Admin"
}

Volumes для БД будет создан на уровень выше корневой директории