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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

#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'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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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