Как изменить стандартную модель пользователя django для моих потребностей?

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

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

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

Как мне это сделать?

ОТВЕТЫ

Ответ 1

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

Для одного сайта я использовал поле "first_name" в качестве "публично отображаемого имени" пользователя и наполнил его расширенной версией в поле "имя пользователя" (для использования в URL-адресах). Я написал собственный сервер аутентификации, чтобы люди могли войти в систему, используя свое "публичное имя" или их адрес электронной почты, и я соблюдаю уникальность обоих из них во время регистрации. Это хорошо работает с другими приложениями многократного использования и не вводит дополнительные таблицы или запросы.

Для другого сайта я вообще не хотел использовать имена пользователей, просто уникальные электронные письма. Чтобы удовлетворить потребность Django в уникальном имени пользователя, я просто испортил адрес электронной почты и использовал это как имя пользователя (вы должны кодировать base64 хэш, чтобы сжать его под 30 символами). Пользовательский auth backend, чтобы разрешить вход с помощью электронной почты.

Если обратная совместимость не была проблемой, есть много улучшений, которые мне бы хотелось увидеть в django.contrib.auth и модели User, чтобы сделать их более гибкими. Но там довольно много вы можете сделать внутри текущих ограничений с небольшим творчеством.

Ответ 2

Модель пользователя Django структурирована очень разумно. Вы действительно не хотите разрешать произвольные символы в имени пользователя, например, и есть способы достичь входа в адрес электронной почты, без взлома изменений к базовой модели.

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

Если вы хотите на самом деле изменить основную модель пользователя, но также "играть хорошо" с многоразовыми приложениями, которые полагаются на нее, вы открываете бит Pandora Box. Разработчики делают базовые предположения о том, как структурирована основная библиотека, поэтому любые изменения могут привести к неожиданному поломке. Тем не менее, вы можете изменить monkeypatch в базовую модель или поместить копию Django локально. Я бы отговорил последнего и рекомендую только первое, если вы знаете, что делаете.

Ответ 3

Я неправильно понял вопрос. Надеюсь, что этот пост будет полезен для всех остальных.

#in models.py
from django.db.models.signals import post_save  

class UserProfile(models.Model):  
    user = models.ForeignKey(User)  
    #other fields here

    def __str__(self):  
          return "%s profile" % self.user  

     def create_user_profile(sender, instance, created, **kwargs):  
        if created:  
           profile, created = UserProfile.objects.get_or_create(user=instance)  

post_save.connect(create_user_profile, sender=User) 

#in settings.py
AUTH_PROFILE_MODULE = 'YOURAPP.UserProfile'

Это создаст пользовательский файл каждый раз, когда пользователь будет сохранен, если он будет создан. Затем вы можете использовать

  user.get_profile().whatever

Вот еще информация из документации

http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users

Ответ 4

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

  • Измените модель User самостоятельно, по предложениям Даниэля
  • Запишите класс CustomUser, подклассифицируйте User или скопируйте его функциональные возможности.

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

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

Ответ 5

Существует несколько способов сделать это, но вот что я сделал бы: я бы разрешил пользователю вводить электронное письмо, имя пользователя (которое должно содержать хотя бы одну букву и символы @) или номер мобильного телефона, Затем, когда я проверяю его:

  • Проверьте наличие @. Если это так, установите его как адрес электронной почты пользователя, хэш его соответствующим образом и установите его как свое имя пользователя.
  • Убедитесь, что это только цифры, тире и +. Затем разделите соответствующие символы и сохраните их как номер мобильного телефона, так и имя пользователя (если вы сохраняете номер мобильного телефона в другой модели для целей SMS или что-то еще).
  • Если это не так, просто укажите его как имя пользователя.

Я также проверял бы поле user/phone/email аналогично при входе в систему и смотрел в нужное место, чтобы, если, скажем, пользователь подписался со своим мобильным номером, а затем изменил свое имя пользователя (для какой-то другой цели) они все равно могут войти с мобильным номером.