Как запустить проект

Склонируйте проект:

https://github.com/BernarBerdikul/Auth_sprint_1.git

На одном уровне с папкой проекта "./Auth_sprint_1" создайте папку "./postgres_data" монтирования к образу Postgres

Для запуска проекта следует скопировать файл .env.example и переименовать на .env

cp .env .env.example

Значение некоторых переменных окружения:

• DB_NAME - название основной БД, которая используется в проекте
• DB_TEST_NAME - отдельная БД для запуска и прогонки тестов
• TESTING (True | False) - значение отвечает за использование тестовой БД в проекте или нет

Создание БД может занять много времени, выполним отдельно

docker-compose -f docker-compose.yml build postgres_db
docker-compose -f docker-compose.yml up -d postgres_db

Запустить проект совместно с тестами и помощью Docker

docker-compose -f docker-compose-test.yml build
docker-compose -f docker-compose-test.yml up

Запустить проект с помощью Docker

docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml up

После запуска проекта, у вас будет доступ к документаций проекта Ссылка на документацию проекта

Проектная работа 6 спринта

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

В первом спринте модуля вы напишете основу вашего сервиса и реализуете все базовые требования к нему. Старайтесь избегать ситуаций, в которых один из ваших коллег сидит без дела. Для этого вам придётся составлять задачи, которые можно выполнить параллельно и выбрать единый стиль написания кода.

К концу спринта у вас должен получиться сервис авторизации с системой ролей, написанный на Flask с использованием gevent. Первый шаг к этому — проработать и описать архитектуру вашего сервиса. Это значит, что перед тем, как приступить к разработке, нужно составить план действий: из чего будет состоять сервис, каким будет его API, какие хранилища он будет использовать и какой будет его схема данных. Описание нужно сдать на проверку. Вам предстоит выбрать, какой метод организации доступов использовать для онлайн-кинотеатра, и систему прав, которая позволит ограничить доступ к ресурсам.

Для описания API рекомендуем использовать OpenAPI{target="_blank"}, если вы выберете путь REST. Или используйте текстовое описание, если вы планируете использовать gRPC. С этими инструментами вы познакомились в предыдущих модулях. Обязательно продумайте и опишите обработку ошибок. Например, как отреагирует ваш API, если обратиться к нему с истёкшим токеном? Будет ли отличаться ответ API, если передать ему токен с неверной подписью? А если имя пользователя уже занято? Документация вашего API должна включать не только ответы сервера при успешном завершении запроса, но и понятное описание возможных ответов с ошибкой.

После прохождения ревью вы можете приступать к программированию.

Для успешного завершения первой части модуля в вашем сервисе должны быть реализованы API для аутентификации и система управления ролями. Роли понадобятся, чтобы ограничить доступ к некоторым категориям фильмов. Например, «Фильмы, выпущенные менее 3 лет назад» могут просматривать только пользователи из группы 'subscribers'.

API для сайта и личного кабинета

• регистрация пользователя;
• вход пользователя в аккаунт (обмен логина и пароля на пару токенов: JWT-access токен и refresh токен);
• обновление access-токена;
• выход пользователя из аккаунта;
• изменение логина или пароля (с отправкой email вы познакомитесь в следующих модулях, поэтому пока ваш сервис должен позволять изменять личные данные без дополнительных подтверждений);
• получение пользователем своей истории входов в аккаунт;

API для управления доступами

• CRUD для управления ролями:
  • создание роли,
  • удаление роли,
  • изменение роли,
  • просмотр всех ролей.
• назначить пользователю роль;
• отобрать у пользователя роль;
• метод для проверки наличия прав у пользователя.

Подсказки

1. Продумайте, что делать с анонимными пользователями, которым доступно всё, что не запрещено отдельными правами.
2. Метод проверки авторизации будет всегда нужен пользователям. Ходить каждый раз в БД — не очень хорошая идея. Подумайте, как улучшить производительность системы.
3. Добавьте консольную команду для создания суперпользователя, которому всегда разрешено делать все действия в системе.
4. Чтобы упростить себе жизнь с настройкой суперпользователя, продумайте, как сделать так, чтобы при авторизации ему всегда отдавался успех при всех запросах.
5. Для реализации ограничения по фильмам подумайте о присвоении им какой-либо метки. Это потребует небольшой доработки ETL-процесса.

Дополнительное задание

Реализуйте кнопку «Выйти из остальных аккаунтов», не прибегая к хранению в БД активных access-токенов.

Напоминаем о требованиях к качеству

Перед тем как сдать ваш код на проверку, убедитесь, что

• Код написан по правилам pep8: при запуске линтера{target="_blank"} в консоли не появляется предупреждений и возмущений;
• Все ключевые методы покрыты тестами: каждый ответ каждой ручки API и важная бизнес-логика тщательно проверены;
• У тестов есть понятное описание, что именно проверяется внутри. Используйте pep257{target="_blank"};
• Заполните README.md так, чтобы по нему можно было легко познакомиться с вашим проектом. Добавьте короткое, но ёмкое описание проекта. По пунктам опишите как запустить приложения с нуля, перечислив полезные команды. Упомяните людей, которые занимаются проектом и их роли. Ведите changelog: описывайте, что именно из задания модуля уже реализовано в вашем сервисе и пополняйте список по мере развития.
• Вы воспользовались лучшими практиками описания конфигурации приложений из урока.