Best practies? Две независимые модели для пользователя и админа, Django 1.11.x?

Question

[Vic Shóstak]

Всем доброго времени года!

После ударных месяцев поддержки разных API и мелких сайтиков на Flask/Bottle/Sanic, знакомые подкинули нулевой проект на Django 1.11.x (причём буквально «нулевой»: создано пару моделей, разделены настройки по окружениям, прописаны начальные тесты и тому подобное). С Джангой я знаком только с бородатой 1.6 версией (потом затянуло в пучину Laravel), и ничего серьёзней «Hello World» на нём не делал, а поучаствовать в проекте есть желание (в том числе, чтобы узнать Django по-лучше) :(

[лирика] Тема проекта: сайт-блог для владельцев собачек-кошечек-хомяков-etc, с пожертвованиями на лечение животных из приютов Петербурга (да-да, пора бы уже плюс в карму сделать, проект нон-профит). Соответственно, должен быть личный кабинет, где все эти транзакции пишутся, ибо планируется подключение онлайн кассы с ОФД (чтобы не нарушать 54-ФЗ). Зачем? Ну вообще закон надо соблюдать, да и потом отчитываться в налоговой, говорят, проще будет (сбор средств для животинок, а не своей наживы — всё по белому должно быть). [/лирика]

Итак, сам вопрос. Есть ли какие-либо проверенные и рабочие best practies для осуществления вот такой системы:

1. Есть стандартный суперпользователь + модераторы сайта (модель User, которая из коробки);
   
2. Есть модель для пользователей-меценатов CustomUser (с полями для личной инфы, телефона, etc);
   
3. Эти две модели не должны пересекаться, то есть наследоваться или работать через proxy (две разных таблицы БД);
   
4. Должна быть и стандартная авторизация для модели User, и отдельная — для модели CustomUser;
   
5. Только модель CustomUserвидна в публичной части сайта (аля «больше всех в этом месяце помог [...], прислав [...]»;
   
6. У CustomUser должен быть (приватный) личный кабинет (вне админки), со всеми транзакциями и редактированием;
   

[ремарка] Сама модель CustomUser — это что-то типа «покупатель пожертвования» (жесть, но по-другому не могу объяснить). То есть, планируется делать некие фиксированные «бандлы» с фирменными безделушками от партнёров (типа «1000 руб. = магнитик», «5000 руб. = футболочка» и так далее), чтобы нельзя было жертвовать произвольную сумму + что-то осталось на память :) [/ремарка]

Собственно, буду рад толковым комментариям и предложениям! Заранее спасибо.

P.S. я понимаю, что никто не даст тут «готового кода на блюдечке», но алгоритм построения такой системы — уже хлеб :D

Comments

[Roman K]

Зачем делить юзеров? Им будет неуютно в одной таблице?

[Vic Shóstak]

Roman Kitaev: просто не хочется заморачиваться с проверками, типа is_stuff и показывать стандартную админку + страницу авторизации (site.com/admin/). Раз в коде CustomUser, то сразу ясно, что это отдельный пользователь с отдельными редиректами после входа и всем таким + никак не связанный с коробочным User.

[Roman K]

Vikky Shostak: Поверь, заморачиваться с авторизацией двух моделей придётся куда сильней. И да, есть менеджеры и прокси-модели.

[sim3x]

Ето не только гемор со стороны джанги, но и не правильно со стороны 3нф БД

Answer 1

[Евгений]

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

Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

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

TLDR:
1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.

Comments

[Vic Shóstak]

Спасибо, очень содержательно и полезно.

На вопрос «почему так» — ответ простой, уже достался такой скелет проекта. За неимением большого опыта в Django (особенно такого уровня задач), он был принят как само собой разумеющееся, но чутьё подсказывало спросить у более опытных кодеров варианты best practies :D

Значит лучше всего делать через AbstractUser, хорошо. А, может быть, поясните разницу между этой моделью и AbstractBaseUser, если не сложно. И где стоит использовать proxy?

[Евгений]

Vikky Shostak: AbstractUser уже определяет большинство полей необходимых пользователю. Насколько я понимаю, AbstractBaseUser нужен для реализации совсем кастомного пользователя, который радикально отличается от стандартного пользователя Django.

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

Есть ли серьезные причины делать разделение на две таблицы? Ну вот правда, есть? С точки зрения безопасности точно нет, так как все части приложения будут иметь доступ ко всем таблицам и в случае нарушения безопасности это никак не поможет.

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

[Vic Shóstak]

Евгений: в очередной раз, спасибо, Евгений! Да, вы правы, но лучше один раз спросить, чем потом жить с таким проектом, краснея, когда даёшь смотреть исходники новому участнику проекта. Плюс для потомков останется, кто будет искать подобное в гугле :)

Про proxy, я имел ввиду, что в последних версиях Django есть возможность расширять модели без создания таблиц в БД (как я понял из доков). Так вот, в каких случаях (моделях) стоить применять такое решение? Нашёл вот такую статью-сравнение, но так и не понял «когда и что» лучше применить :)

[Евгений]

Vikky Shostak
Краснеть все равно придется, это неизбежно. Даже Кнут делает ошибки. :)

Я делаю проекты от тривиальных до очень сложных на Python/Django уже 10 лет. И вот поверьте, ни разу в моей практике мне не требовалось что-то подобное proxy. Хотя задачи порой были сложные и нетривиальные. Просто забудьте пока об этой возможности и все.

Думаю, что это требуется прежде всего в старых legacy системах, переписываемых на Django. Когда, например, приложение должно работать с таблицей не напрямую, а через хранимую процедуру.

Но на самом деле, забудьте. Вы занимаетесь тем, что называется overengineering. Вам (хотя бы в первом проекте) надо придерживаться принципа KISS: делайте все как можно проще используя по максимуму стандартные решения Django. Пользователи Django, группы Django, обычные таблицы, без наследования (за исключением ровно одной таблицы — AbstractUser), обычные Class Based Views из django.views.generic. Если чего-то не хватает, берите самые используемые и поддерживаемые пакеты из перечисленных на djangopackages.com. Например, вместо изобретения велосипедов с логином и регистрацией, используйте django-allauth.

Изучайте код хороших приложений на Django. Например:

• https://github.com/taigaio/taiga-back/
  
• https://github.com/edx/edx-platform/
  
• https://github.com/djangopackages/djangopackages/
  
• https://github.com/mozilla/bedrock/
  
• https://github.com/mozilla/addons-server/
  
• https://github.com/mozilla/kuma/
  
  

[Евгений]

P.S. Статья-сравнение ссылку на которую вы привели - полная хрень. Явно высосано из пальца ради наполнения блога. Например, расширение профиля через OneToOneField - это костыль, существоваший на заре Django из-за ограничений ORM Django в то время. В 2016 году, когда писалась данная статья, почти никакого смысла так поступать нет. Ни в одной ситуации.

И дальше в статье много ошибок и ложных указаний. Явно написано для привлечения рекрутеров («смотрите, я веду блог о Django, наверное меня стоит взять на работу!»)

[Vic Shóstak]

Евгений: огромное спасибо, Евгений за то, что поделились опытом! Буду изучать ссылки. А за комментарий по той статье — вообще низкий поклон, удалю из избранного :D

Раз уж пошла такая пьянка, то спрошу совета по регистрации пользователей :) Как сделать процесс регистрации, в ситуации, когда нужно регистрировать пользователя только когда он сделал первое пожертвование (аля заказ)? Тут есть некая сакральная причина для статистики, чтобы просто не было пользователей, которые ничего не пожертвовали, а просто зарегистрировались.

С авторизацией, я думаю, можно пока обойтись без django-allauth (на данном этапе, по социалкам вход не нужен) и просто пользоваться простейшим примером из документации (для унаследованной модели пользователя): https://docs.djangoproject.com/en/1.11/topics/auth... Или это тоже не самое лучшее решение?

[Евгений]

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

django-allauth решает все вопросы аутентификации. Аутентификация через соц. сети - это лишь приятное дополнение, которым пользоваться не обязательно. Зато потом вы сможете добавить 2-3 строки в настройки и она у вас заработает.

Что касается регистрации вместе с пожертвованием... Ну, просто сделать свою собственную форму регистрации, которая одновременно занимается и регистрацией пользователя и собиранием пожертвования. Первое что пришло в голову.

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

Вы сильно тяготеете к усложнению всего. :)

[Vic Shóstak]

Евгений: что есть, то есть. Причём, не специально это у меня получается :( Наоборот, всегда стараюсь следовать Python-дзену «простое лучше, чем сложное». Пока не складывается в голове, что в самом ТОП веб-фреймворке на Python — почти всё уже есть из коробки. Чего нет — можно найти в сторонних пакетах. Без великов и костылей. Видимо, остаточное после Flask/Bottle :D

По «усложнённой» регистрации, спасибо. Буду думать, как упростить это. Пока что в голову приходит просто заказ в два шага: выбираем бандл > заполняем данные о себе и пароль > отправляем. Это сохраняется, например, в сессию. Переходим на страницу оплаты (какой-нибудь агрегатор, типа Яндекс.Кассы на первое время). После успешной оплаты — всё это дело из сессии сохраняем (и нового пользователя и его первый заказ). Если пользователь уже вошёл на сайт, то при заказе бандла — идём сразу к оплате.

[Евгений]

Vikky Shostak это не будет нормально работать, потому что может сломаться во многих местах.
Например, валидация пользователя может пройти в первый раз, но между сохранением в сессию, оплатой, и созданием реального пользователя, может зарегистрироваться другой пользователь с тем же именем и email. И что тут делать? Никакого разумного решения, кроме адских костылей не придумать.

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

Я бы на первом этапе создавал пользователя в базе сразу, с флагом `is_active = False` (этот флаг - часть стандартного класса пользователя Django). Если оплата прошла успешно, то ставил бы `is_active = True`. Заодно потом и статистику легко посчитать по `is_active`.

[Vic Shóstak]

Евгений: OMG! Евгений, вы открыли мне глаза. Точно же, так гораздо проще.. и в понимании процесса и при валидации! :)

И ещё вопросик: надо же наследоваться вот так? https://docs.djangoproject.com/en/1.11/topics/auth... то есть обязательно нужно перезаписывать модель User? А можно ли назвать её CustomUser, например? Чего-то не очень понял из документации всю эту штуку с наследованием от AbstractUser...

[Евгений]

Вот пример из реального приложения:

class Profile(AbstractBaseUser, PermissionsMixin):
    username = models.CharField('username', max_length=50, unique=True,
                                help_text='Required. 50 characters or fewer. Letters, digits and ' 
                                          '@/./+/-/_ only.',
                                validators=[
                                    validators.RegexValidator(r'^[\w.@+-]+$',
                                                              'Enter a valid username. ' 
                                                              'This value may contain only letters, numbers '
                                                              'and @/./+/-/_ characters.')
                                ],
                                error_messages={
                                    'unique': "A user with that username already exists.",
                                })
    first_name = models.CharField(max_length=30, blank=True)
    last_name = models.CharField(max_length=30, blank=True)
    email = models.EmailField('email address', blank=True)
    is_staff = models.BooleanField(
        'staff status',
        default=False,
        help_text='Designates whether the user can log into this admin site.',
    )
    is_active = models.BooleanField(
        'active',
        default=True,
        help_text='Designates whether this user should be treated as active. '
                  'Unselect this instead of deleting accounts.'
    )
    date_joined = models.DateTimeField('date joined', default=timezone.now)

    picture = models.ImageField(upload_to="uploads/profile/", null=True, blank=True)

    objects = UserManager()

    USERNAME_FIELD = 'username'
    REQUIRED_FIELDS = ['email']

    def __str__(self):
        return self.username

    def get_short_name(self):
        return self.first_name

    def get_full_name(self):
        return '{0.first_name} {0.last_name}'.format(self)

Как называется модель не имеет значение, лишь бы не было конфликта имен (в Python коде или в базе). Можно и User назвать. Можно ИмяПроектаUser. Это вопрос личных предпочтений. У меня во многих проектах исторически называется Profile (потому что начинались они, когда расширять стандартную модель было нельзя, затем объединил модели, но название осталось прежним).

[Евгений]

Только заметил, что унаследовался от AbstractBaseUser. Уже не вспомню, почему так сделал. Логичнее было бы от AbstractUser, т.к. я его по большей части переписал, получается - лишняя работа.

[Vic Shóstak]

Вот, у меня есть проект, в нём создаю приложение custom_user. Полностью дропаю всю БД и файлы миграций (благо, что всё локально, без данных).

# settings.py
...
AUTH_USER_MODEL = 'custom_user.CustomUser'
...

# models.py
from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    pass

# admin.py
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import CustomUser

admin.site.register(CustomUser, UserAdmin)

Потом делаю первоначальный ./manage.py migrate, но вижу ошибку, что таблица custom_user_customuser ещё не создана. Что я делаю не так? Может быть есть более how-to инструкция (актуальная) по наследованию пользовательской модели? А то всё, что удалось найти в гугле — через О2О к User предлагают делать. Даже в ссылках, которые вы мне посоветовали, делают так: https://github.com/djangopackages/djangopackages/b...

[Евгений]

Мне тяжело ответить на каждый ваш вопрос, у меня своя работа есть и ее много.

Сначала надо сделать makemigrations для новой модели

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

[Vic Shóstak]

Евгений: да, я понимаю, извиняюсь за такой напор вопросов.. спасибо, ещё раз, огромное, что вообще опытом/кодом/ссылками поделились! Даже на это не рассчитывал тут, если честно :)

Answer 2

[un1t]

Делаешь одну модель, добавляшь ей поле role например. И по ней потом даешь доступы.

Comments

[Vic Shóstak]

Под «Делаешь одну модель [...]» понимается «наследуешься от коробочной User»?

[un1t]

Тока не от User, а от AbstractBaseUser
https://docs.djangoproject.com/en/1.11/topics/auth...

Answer 3

[Anatoly Scherbakov]

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

Я думаю, что проще всего использовать стандартную модель User + свою модель Profile, подключённую через OneToOneField. В ней можно собирать все необходимые свойства. Что мешает модератору сайта одновременно быть покупателем футболочек? Собственно ничего.

А теперь что касается проверок на is_staff. Посмотрите django-braces. Вам достаточно использовать class based views и подключать нужные mixins, - и вы забудете об этих проверках: большая их часть будет выполняться в mixins, а не в бизнес-логике предметной области. Вы можете и свои классы для этого дела написать.

Comments

[Roman K]

Вот не надо советовать связывать юзера O2O связью с доп. полями. Давным давно модель юзера расширяется легко и просто.

[Vic Shóstak]

Roman Kitaev: я так понимаю, что через proxy? Вообще, что лучше использовать? Нашёл вот такую статью, но какое решение (в рамках данного проекта) выбрать, пока, не понял.

[Roman K]

Vikky Shostak: https://docs.djangoproject.com/en/1.11/topics/auth...

[Евгений]

django-braces уже большей частью не нужен: большая часть его функциональности уже есть в core Django в модуле django.contrib.auth.mixins.