neoduss / auth_sprint_1-2 Goto Github PK

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

Упростите регистрацию и аутентификацию пользователей в Auth-сервисе, добавив вход через социальные сервисы. Список сервисов выбирайте исходя из целевой аудитории онлайн-кинотеатра — подумайте, какими социальными сервисами они пользуются.
Вам не нужно делать фронтенд в этой задаче и реализовывать собственный сервер OAuth. Нужно реализовать протокол со стороны потребителя.
Информация по OAuth у разных поставщиков данных:
Twitter,
Facebook,
VK,
Google,
Yandex,
Mail.
Дополнительное задание
Реализуйте возможность открепить аккаунт в соцсети от личного кабинета.
Решение залейте в репозиторий текущего спринта и отправьте на ревью.

Накидать методы с нужными параметрами (name, password, etc.)

Создайте интеграцию Auth-сервиса и AsyncAPI-сервиса, используя контракт, который вы сделали.
При создании интеграции не забудьте учесть изящную деградацию Auth-сервиса. Как вы уже выяснили ранее, Auth сервис один из самых нагруженных, потому что в него ходят большинство сервисов сайта. И если он откажет, сайт отказать не должен. Обязательно учтите этот сценарий в интеграциях с Auth-сервисом.

Сделать двухфакторную аутентификацию
Для запуска приложения понадобится:
flask==1.1.2
pyotp==2.4.1
uvicorn==0.12.3
python-multipart==0.0.5

Сейчас сервис Auth беззащитен перед DDOS-атаками. Чтобы сберечь важный элемент системы от чрезмерной нагрузки, которая может вывести его из строя, реализуйте алгоритм Leaky bucket или Token bucket, используя Redis для синхронизации реплик. Впоследствии вы можете делегировать эту обязанность сторонниму инструменту, например, Cloudflare.

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

Код хороший, однако, не смог запустить проект (про это в п.п. 5-6):

1. Сервис авторизации как и остальные сервисы проекта, взаимодействующие с пользователем, должен отдаваться через nginx.
2. При запуске сервиса, перед применением миграций нужно добавить скрипт ожидания запуска БД. Иначе не заводится.
3. Выдача истории входов пользователя должна быть с пагинацией, там через 2-3 месяца будут выдаваться сотни записей.
4. Обязательно должно быть версионирование адресов "ручек" и папок в проекте. У вас, кажется, были мысли в этом направлении, но дальше создания папки src/app/api/v1 не пошло.
5. При повторном запуске проекта получаю: Error: Directory migrations already exists and is not empty.
6. Команда flask db init выполняется один раз кем-то из разработчиков, она создаст необходимую инфраструктуру для миграций, затем так же запуск flask db migrate -m "Initial migration." когда нужно и тоже вручную создают миграции. И все это отправляют в репозиторий. Ни в коем случае это все нельзя делать автоматически. Автоматически при запуске проекта допускается только применение миграций.
7. Для разделения логики приложения авторизацию и работу с ролями лучше разнести по разным blueprint.
8. Вы историю посещений пользователя отдаете по POST запросу. Это, как минимум, странно.
9. Судя по всему у вас управление ролями доступно всем. Нужно предусмотреть создание суперпользователя и разрешать это только ему. Flask предоставляет механизм создания консольных команд: https://flask.palletsprojects.com/en/2.1.x/cli/#custom-commands
10. А для проверки прав пользователя при управлении ролями можно попробовать вот это https://flask-jwt-extended.readthedocs.io/en/stable/custom_decorators/

Подготовьте Auth сервис к интеграции с другими сервисами вашего сайта. Сгенерируйте схему взаимодействия с Auth сервисом в формате, который используется в вашем сервисе.

1. Создать модели для таблиц

2. При помощи SQL-alchemy запилить миграцию таблиц по моделям в БД

Получает информацию от check_user и работает с БД

1. Работа с токенами (INSERT / UPDATE / DELETE)
2. Работа с личными данными / историей и т.д

Добавьте в Auth трасировку и подключите к Jaeger. Для этого вам нужно добавить работу с заголовком x-request-id и отправку трасировок в Jaeger.

Компонент отвечает за проверку авторизационных данных (токены, пароли и т.д)

1. При создании пользователя проверяет, что такого нет в системе
2. При отправке запроса проверяет наличие токена и его валидность
3. Проверяет срок действия токенов refresh / access

Сделать капчу

Хорошая работа! Реализовали все задачи. Правильно, что использовали gRPC для межсервисного взаимодействия. Это один самых правильных подходов.

1. Имя провайдера внешней авторизации лучше поместить в enum. Во-первых, в будущем при разрастании проекта вам может понадобится использовать имя провайдера в различных частях приложения. Во-вторых, использование enum избавляет от опечаток в строковых литералах. Можно случайно прописать кириллический символ в строке и потом очень долго гадать из-за чего возникла ошибка.
2. Вместо print лучше использовать logging. print'ом невозможно управлять и ваш токен всегда будет записываться в логи, что не есть хорошо с точки зрения безопасности. Если хочется видет токен в процессе разработки, то лучше прописать logging c уровнем debug для токена, а при выкатке приложения в прод прописать общий уровень логирования выше уровня debug, чтобы токен не попадал в stdout. В проекте много где используются print'ы, так что лучше везде настроить логирование через logging.
3. Лучше удалять закомментированный код (тут и тут), если он больше нигде не планируется использоваться. Так код будет проще читать другому программисту и он не будет тратить дополнительное время на чтение закомментированных строк. Если код действительно важен и его панируется использовать в будущем, то можно сделать коммит и в случае чего откатится на него. Или можно сделать отдельную ветку для таких целей, чтобы в случае чего вмерджить эту функциональность в dev/master ветку. Желательно почистить от закомментированного кода весь проект :)
4. Тут нет необходимости открывать порт во внешнею сеть для межсервисного взаимодействия через gRPC. EXPOSE вполне достаточно.
5. В целях безопасности, лучше не выставлять лишние порты наружу, особенно порты БД. В идеале, наружу должен смотреть только 80 порт от nginx.