Поменять мертвые пакеты

[kazqvaizer]

Хвала AI, нашел такие пакеты, которые никто не котрибьютил, более года, надо глянуть, что есть по альтернативам (Grok не справился):

• https://pypi.org/project/types-freezegun/ - поменять на https://github.com/python/typeshed
• https://pypi.org/project/pytest-deadfixtures/ вроде ожил!
• https://pypi.org/project/mixer/ - меняем тут Найти альтернативы миксеру #774
• https://pypi.org/project/drf-jwt/ - меняем тут Заменить мертвый пакет drf-jwt #763
• https://pypi.org/project/djangorestframework-camel-case/
• https://pypi.org/project/django-healthchecks/ - меняем тут Заменить django-healthchecks на свой простой healthcheck #801
• https://pypi.org/project/django-behaviors/

[kazqvaizer]

@nkiryanov посмотри в этот тред тоже, пожалуйста

[f213]

https://pypi.org/project/django-behaviors/

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

[alexeybogoslovsky]

Еще брали SluggedModel, но кажется, лучше тоже свою реализацию сделат

[kazqvaizer]

Еще брали SluggedModel

Я в последнее время забиваю на эту штуку, она иногда глючит и проще просто добавить SlugField.

Думаю в самом деле нужно выкинуть этот пакет behaviors.

[f213]

У меня есть неспешное предложение по поводу JWT.

Если будет альтернативный пакет без жуткого симбиоза сериализаторов и логики, будет круто!

Кажется идеально было бы сделать реализацию JWT без пакета вообще. Проблема всех реализаций JWT для DRF в том, что они:

1. Пытаются быть конфигурируемыми декларативно — хотя пара строк кода были бы гораздо более выразительны.
2. Пытаются переиспользовать куски DRF, которые для этого не подходят.

Кажется, если просто написать пару вьюх по 5 строчек — можно будет выкинуть ещё одну зависимость. В школе я потихоньку перетаскиваю всю реализацию JWT в приложение a12n — получается просто и понятно. Как будет какой-то промежуточный результат — вернусь сюда и покажу.

[kazqvaizer]

Согласен, все реализации JWT для DRF прикованы к сериализаторам и жутко плохо написаны.

У меня вообще более глобальное предложение - перейти на стандартные Django сессии. Дело в том, что наши JWT все равно не стейтлес по настоящему - все равно мы запрашиваем данные пользователя каждый раз и в идеале еще проверим черный список токенов. Поэтому еще один запрос в БД за сессией не сильно повлияет на картину.

Могу представить себе какие-то проблемы с CORS или возможные проблемы с мобилками, но кажется все это можно без особых проблем митигировать.

На одном проекте внутри мы уже используем сессии и для обычного веба это не создает проблем.

[f213]

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

Прямо сейчас на одном из проектов у нас используются джанговские JWT, чтобы аутентифицировать пользователей в соседнем сервисе (centrifugo), который вообще ничего не знает о базе юзеров.

Так же на моей памяти был сетап, в котором мы хранили в JWT несколько ID пользователей для интеграции с легаси — новая система смотрела на свои ID, легаси — на свои. С сессиями всего этого не сделать — вернее сделать, но гораздо сложнее.

[kazqvaizer]

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

Так нет же - сквозной на всех ключик как раз и повышает связность.

Мой опыт интеграции со сторонними системами (с авторизацией на стороне пользователя и редиректорм) говорит о том, что все равно приходится делать отдельный класс, который генерит JWT токены под конкретную систему со своими claims, не получится сделать один для всех. То что так получилось с centrifugo - кайф, но не получится, например, с grafana или с опенсорсным плагином валидации JWT для nginx.

В общем, мой тейк такой, что шеймить сессии точно не стоит и, возможно, в некоторых случаях можно вообще не велосипедировать с JWT либами и делать по KISS. Если понадобится несколько связанных сервисов с авторизацией, ну ок, сделаем одноразовый токен редирект в другой сервис и пусть внутри этого другого сервиса работает своя авторизация, будь то session, будь то bearer.

[f213]

Согласен! Кажется здесь довольно простая дихотомия: что оставлять в стартере — JWT или сессии. В любом случае каждый проект будет делать ту аутентификацию, которую посчитает нужной.

Я пока всё ещё для JWT для стартера, т.к. гораздо проще сказать «мы поддерживаем JWT», чем сказать «у нас всё на сессиях, но это никак не привязано к реализации». Готов обсудить голосом

[kazqvaizer]

Я пока всё ещё для JWT для стартера, т.к. гораздо проще сказать «мы поддерживаем JWT»,

Да, я тоже поддерживаю, не вижу причин резко менять концепцию, плавно добавим сюда кастомных вьюх, думаю, будет ок.

[f213]

pytest-deadfixtures кажется ожил! надеюсь, будет и дальше развиваться