Открытая библиотека django-swap-user для простой кастомизации Django User

July 2022

Фреймворк Django для веб-приложений на Python очень популярен. Модель пользователя в Django по умолчанию включает в себя электронную почту, имя пользователя и пароль. Но нередко бывают ситуации, когда эту модель необходимо расширить или заменить.

Например, вам не нужно имя пользователя, а нужен только адрес электронной почты, или вместо адреса электронной почты нужно указать номер телефона. В таких ситуациях модель по умолчанию требуется заменить на кастомную, которая включает нужные вам поля. Именно для такой замены и предназначен проект django-swap-user.

Кроме того, в настоящее время начинает набирать популярность авторизация с помощью одноразового кода. Мы учли в библиотеке и этот сценарий. Когда появляется новая модель пользователя, она содержит только одно поле — email или phone — плюс одноразовый код доступа. Пароль не нужно хранить в базе данных: SMS с одноразовым паролем для входа в систему отправляется через любого провайдера, к которому вы подключены.

Зачем мы написали для этого целую библиотеку? Когда начинается работа над новыми проектами, часто требуется кастомная модель пользователя. Раньше мы копировали её из одного проекта в другой, но потом пришли к выводу, что рациональнее использовать библиотеку, чем без конца копировать модули. Готовой современной поддерживаемой библиотеки мы не нашли, поэтому наш Python-лид Артём Иннокентьев сам написал и выложил на GitHub эту оболочку.

Итак, этот пакет избавит вас от постоянного копирования кастомной модели пользователя из проекта в проект.

Установка

pip install django-swap-user

Архитектура

Пакет swap_user содержит несколько приложений:

to_email — предоставляет модель пользователя с полем email;
to_email_otp — предоставляет модель пользователя с полем email и аутентификацию с помощью одноразовых паролей
to_phone — предоставляет модель пользователя с полем phone
to_phone_otp — предоставляет модель пользователя с полем phone и аутентификацию с помощью одноразовых паролей

Почему выбрана такая необычная архитектура

Если объединить эти приложения в одно, все они будут создавать миграции и таблицы, что приведет к избыточным таблицам. Они будут рассматриваться как три кастомные модели в одном и том же приложении — это приведёт к путанице.

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

Мы смоделировали этот подход на основе приложения Django REST Framework authtoken, подробнее здесь.

Использование кастомной модели на старте проекта

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

Внедрение модели в середине проекта

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

Выполните все шаги в тестовой базе данных и ТОЛЬКО В ТОМ СЛУЧАЕ, если все они прошли успешно, попробуйте повторить их в рабочей среде
Обратите внимание, что эти шаги применимы для большинства случаев, но иногда может потребоваться их адаптация к ситуации
Создайте резервную копию вашей БД
Добавьте в репозитарий тег или сохраните хэш последнего коммита, чтобы легко откатиться к нему
Плюньте через левое плечо! :D
Удалите в каждом приложении Django-проекта все миграции
Удалите все записи из таблицы django_migrations, например, с помощью SQL-запроса TRUNCATE django_migrations
Теперь вы можете изменить модель по умолчанию
Сгенерируйте новые миграции для всех приложений — python manage.py makemigrations
Теперь нужно выполнить миграцию с параметром —fake, поскольку у вас уже есть все таблицы с данными
Сначала примените fake к приложению auth, поскольку вы зависите от него: python manage.py migrate —fake auth
Установите библиотеку, следуя инструкциям, и примените миграции
Затем примените fake к остальным миграциям — python manage.py migrate —fake
Запустите ваше приложение

Планы на будущее

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

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

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

Я задумывал эту библиотеку как набор готовых кастомных моделей юзера, но в один момент пришло осознание, что OTP — это еще один из набирающих популярность кейсов. Именно поэтому решено было добавить не только модели пользователя, но и авторизационные бекенды для OTP. Другим кейсом было понимание того, что заменить пользователя в середине проекта достаточно сложно, и в интернете предлагают разрозненные решения данной проблемы. Поэтому я решил предоставить пошаговый гайд по смене модели во время активной фазы разработки. В будущем хочется расширить предоставляемый функционал. Думаем над добавлением авторизации для уже имеющихся моделей, увеличим покрытие тестами, добавим больше кейсов в документацию, настроим CI / CD.

Артём Иннокентьев

Python Teamlead, Evrone

Теги:

Python

Backend