Как изменить данные пользователя django

Once unpublished, all posts by earthcomfy will become hidden and only accessible to themselves.

If earthcomfy is not suspended, they can still re-publish their posts from their dashboard.

Note:

Once unpublished, this post will become invisible to the public and only accessible to Hana Belay.

They can still re-publish the post if they are not suspended.

Thanks for keeping DEV Community 👩‍💻👨‍💻 safe. Here is what you can do to flag earthcomfy:

Make all posts by earthcomfy less visible

earthcomfy consistently posts content that violates DEV Community 👩‍💻👨‍💻’s
code of conduct because it is harassing, offensive or spammy.

Quick Summary:-

In this blog, we will learn how to edit User profile both Django User and custom User fields. And the custom User model is UserProfile.

Prerequisites:-

1. I have used python version 3.6
2. Django version 2.0.2
3. Operating System Ubuntu 16.04
4. MySQL
5. IDE — pycharm-community-2018.2.5

Let’s start to create Django project:- 

Now, create accounts app:-

And run the project-

If we navigate this Url http://127.0.0.1:8000. We’ll see Django welcome page.

Add «accounts» at the bottom of «INSTALLED_APPS». And add the «AUTH_PROFILE_MODULE» config at the bottom of the entire file.

We will add «accounts» app in settings.py and use the «AUTH_USER_MODEL» config to tell Django to use our another model. And our another model will UserProfile.

Update database configuration in settings.py-

where ‘custom’ is database name. And we will create ‘custom’ database through terminal.

In modles.py, we will add UserProfile model.

UserProfile model, that means it is a entity class. And created «accounts_userprofile» table in «custom» database. Where all entry of UserProfile will be store.

In forms.py:-

Django form is a nice thing that we can create a ModelForm which will save the result of the form to the model exactly what we want to do.

In views.py:-

In views.py, we can write our custom view for our HTML templates and will use the ORM to get the data from the database.

In urls.py:-

In the accounts app, we make templates folder and within the templates folder create base.html:-

In templates folder make another accounts folder.
Now we create edit_profile.html and view_profile.html file in accounts folder.

{% block head %}

Profile

{%endblock%}

{%block body%}

In urls.py:-

Now we can run make migrations and migrate commands to create a new database that uses the custom user model.

Conclusion:-
                   In this article, we have covered how to edit User profile both Django User and custom User fields.

Reference:-
              External links to the source code-
              1)- https://www.youtube.com/watch?v=Fc2O3_2kax8&list=PLw02n0FEB3E3VSHjyYMcFadtQORvl1Ssj

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

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

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

Способы расширения существующей модели пользователей

Существует четыре разных способа расширения существующей модели пользователя, о которых пойдет речь в статье:

• использование прокси-модели;
• использование связи один-к-одному с пользовательской моделью;
• создание модели пользователя с помощью расширения класса AbstractBaseUser;
• создание модели пользователя с помощью расширения класса AbstractUser.

Для начала вам необходимо определиться, какой из способов подходит вам больше всего.

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

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

Когда следует использовать прокси-модель?

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

Это то, что мне нужно! Перейти к коду!

Использование связи один-к-одному с пользовательской моделью

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

Когда следует использовать связи один-к-одному?

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

Это то, что мне нужно! Перейти к коду!

Создание модели пользователя через расширение AbstractBaseUser

Это совершенно новая модель пользователя, которая наследуется от AbstractBaseUser. Ее грамотная интеграция требует дополнительных усилий и обновления некоторых связей через settings.py. При выборе этого варианта настоятельно рекомендуется провести все манипуляции с моделями до начала работы над проектом, так как это повлияет на всю схему базы данных. Использование этого способа в готовом проекте может вызвать проблемы при внедрении новой модели.

Когда следует использовать этот способ?

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

Это то, что мне нужно! Перейти к коду!

Создание модели пользователя через расширение AbstractUser

Этот способ также подразумевает создание новой модели пользователя, но которая наследуется уже от AbstractUser. Здесь актуальны все те же замечания, что и для пункта выше: необходимость дополнительных усилий для внедрения и обновления некоторых связей через settings.py, сложности при интеграции в готовый проект.

Когда следует использовать этот способ?

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

Это то, что мне нужно! Перейти к коду!

Расширение модели пользователя через прокси-модель

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

Вот как это можно сделать:

from django.contrib.auth.models import User
from .managers import PersonManager

class Person(User):
    objects = PersonManager()

    class Meta:
        proxy = True
        ordering = ('first_name', )

    def do_something(self):
        ...

В приведенном выше примере создается прокси-модель с именем Person. Тот факт, что она является прокси-моделью, указывается внутри класса Meta: proxy = True.

Сама прокси-модель в этом примере используется для переопределения сортировки по умолчанию, назначения нового Manager и определения нового метода do_something.

Отметим, что User.objects.all() и Person.objects.all() будут обращаться к одной и той же таблице базы данных. Единственное различие заключается в поведении, которое определяется для прокси-модели. Вот и все.

Расширение модели пользователя с помощью связи один-к-одному

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

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

Обычно в Django такие модели называют Profile:

from django.db import models
from django.contrib.auth.models import User

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    bio = models.TextField(max_length=500, blank=True)
    location = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

А теперь установим сигналы для Profile на автоматическое создание/обновление, когда мы создаем/обновляем стандартную модель пользователя (User):

from django.db import models
from django.contrib.auth.models import User
from django.db.models.signals import post_save
from django.dispatch import receiver

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    bio = models.TextField(max_length=500, blank=True)
    location = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

@receiver(post_save, sender=User)
def save_user_profile(sender, instance, **kwargs):
    instance.profile.save()

Как можно видеть, основная нагрузка — это добавление вызовов create_user_profile и save_user_profile всякий раз, когда происходит сохранение (в том числе создание) объекта. Этот вид сигнала называется post_save.

Дадим еще несколько поясняющих примеров. Можно использовать следующий код в шаблоне:

<h2>{{ user.get_full_name }}</h2>
<ul>
  <li>Имя пользователя: {{ user.username }}</li>
  <li>Местоположение: {{ user.profile.location }}</li>
  <li>Дата рождения: {{ user.profile.birth_date }}</li>
</ul>

Или такой внутри представления:

def update_profile(request, user_id):
    user = User.objects.get(pk=user_id)
    user.profile.bio = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit...'
    user.save()

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

Отдельно обсудим вопрос использования форм. Можно использовать более одной формы сразу. Как в этом примере:

# forms.py

class UserForm(forms.ModelForm):
    class Meta:
        model = User
        fields = ('first_name', 'last_name', 'email')

class ProfileForm(forms.ModelForm):
    class Meta:
        model = Profile
        fields = ('url', 'location', 'company')

# views.py

@login_required
@transaction.atomic
def update_profile(request):
    if request.method == 'POST':
        user_form = UserForm(request.POST, instance=request.user)
        profile_form = ProfileForm(request.POST, instance=request.user.profile)
        if user_form.is_valid() and profile_form.is_valid():
            user_form.save()
            profile_form.save()
            messages.success(request, _('Ваш профиль был успешно обновлен!'))
            return redirect('settings:profile')
        else:
            messages.error(request, _('Пожалуйста, исправьте ошибки.'))
    else:
        user_form = UserForm(instance=request.user)
        profile_form = ProfileForm(instance=request.user.profile)
    return render(request, 'profiles/profile.html', {
        'user_form': user_form,
        'profile_form': profile_form
    })

<!-- profile.html -->

<form method="post">
  {% csrf_token %}
  {{ user_form.as_p }}
  {{ profile_form.as_p }}
  <button type="submit">Сохранить изменения</button>
</form>

А теперь о дополнительных запросах к базе данных.

Django будет формировать запрос к базе данных только при доступе к одному из связанных свойств. Иногда это вызывает нежелательные эффекты, такие как запуск сотен или тысяч запросов. Этот эффект можно смягчить, используя метод select_related.

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

users = User.objects.all().select_related('profile')

Расширение модели пользователя с помощью наследования AbstractBaseUser

Это самый сложный вариант, старайтесь избегать его любой ценой. Однако иногда это невозможно.

Допустим, нам нужно использовать адрес электронной почты в качестве логина и использование username совершенно бесполезно. Также у нас нет необходимости в использовании флага is_staff, поскольку мы не будем использовать админку Django.

В таком случае пользовательскую модель можно определить так:

from __future__ import unicode_literals

from django.db import models
from django.core.mail import send_mail
from django.contrib.auth.models import PermissionsMixin
from django.contrib.auth.base_user import AbstractBaseUser
from django.utils.translation import ugettext_lazy as _

from .managers import UserManager


class User(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(_('email'), unique=True)
    first_name = models.CharField(_('name'), max_length=30, blank=True)
    last_name = models.CharField(_('surname'), max_length=30, blank=True)
    date_joined = models.DateTimeField(_('registered'), auto_now_add=True)
    is_active = models.BooleanField(_('is_active'), default=True)
    avatar = models.ImageField(upload_to='avatars/', null=True, blank=True)

    objects = UserManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = []

    class Meta:
        verbose_name = _('user')
        verbose_name_plural = _('users')

    def get_full_name(self):
        '''
        Возвращает first_name и last_name с пробелом между ними.
        '''
        full_name = '%s %s' % (self.first_name, self.last_name)
        return full_name.strip()

    def get_short_name(self):
        '''
        Возвращает сокращенное имя пользователя.
        '''
        return self.first_name

    def email_user(self, subject, message, from_email=None, **kwargs):
        '''
        Отправляет электронное письмо этому пользователю.
        '''
        send_mail(subject, message, from_email, [self.email], **kwargs)

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

• USERNAME_FIELD — строка, описывающая имя поля в модели пользователя, которая используется как идентификатор. Поле должно быть уникальным (то есть иметь значение unique=True, установленное в его определении);
• REQUIRED_FIELDS — список имен полей, которые будут запрашиваться при создании пользователя через команду управления createsuperuser;
• is_active — логический атрибут, указывающий, является ли пользователь активным;
• get_full_name() — более длинный формальный идентификатор для пользователя. В этом примере будем использовать полное имя пользователя, но это может быть любая строка, которая идентифицирует пользователя;
• get_short_name() — короткий «неофициальный идентификатор» пользователя. В нашем примере — имя пользователя.

Также нужно определить UserManager. Это связано с тем, что существующий менеджер определяет методы create_user и create_superuser.

А вот как выглядит UserManager, удовлетворяющий перечисленным выше требованиям:

from django.contrib.auth.base_user import BaseUserManager

class UserManager(BaseUserManager):
    use_in_migrations = True

    def _create_user(self, email, password, **extra_fields):
        """
        Создает и сохраняет пользователя с введенным им email и паролем.
        """
        if not email:
            raise ValueError('email должен быть указан')
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email, password=None, **extra_fields):
        extra_fields.setdefault('is_superuser', False)
        return self._create_user(email, password, **extra_fields)

    def create_superuser(self, email, password, **extra_fields):
        extra_fields.setdefault('is_superuser', True)

        if extra_fields.get('is_superuser') is not True:
            raise ValueError('Superuser must have is_superuser=True.')

        return self._create_user(email, password, **extra_fields)

Он удаляет существующий UserManager, а также имя пользователя и свойство is_staff.

Теперь последний шаг. Нужно обновить settings.py, а именно свойство AUTH_USER_MODEL:

AUTH_USER_MODEL = 'core.User'

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

Как ссылаться на эту модель? Есть два пути. Рассмотрим модель с названием Course:

from django.db import models
from testapp.core.models import User

class Course(models.Model):
    slug = models.SlugField(max_length=100)
    name = models.CharField(max_length=100)
    tutor = models.ForeignKey(User, on_delete=models.CASCADE)

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

from django.db import models
from django.conf import settings

class Course(models.Model):
    slug = models.SlugField(max_length=100)
    name = models.CharField(max_length=100)
    tutor = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)

Расширение модели пользователя с помощью наследования AbstractUser

Здесь все довольно просто, поскольку класс django.contrib.auth.models.AbstractUser обеспечивает полную реализацию пользователя по умолчанию как абстрактную модель:

from django.db import models
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    bio = models.TextField(max_length=500, blank=True)
    location = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

Затем вам как и в предыдущем способе нужно обновить settings.py, определяя свойство AUTH_USER_MODEL:

AUTH_USER_MODEL = 'core.User'

Это нужно сделать перед началом работ над проектом, так как это повлияет на всю схему базы данных. Также старайтесь создавать внешние ключи для модели пользователя, импортируя параметры из from django.conf import settings и ссылаясь на  settings.AUTH_USER_MODEL вместо прямого обращения к новой пользовательской модели.

Выводы

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

Перевод статьи «How to Extend Django User Model»

If you are a Django developer, you might have already noticed that Django comes with a built-in authentication system. Django’s authentication system provides a mechanism for user signup, login, password reset, authentication, and authorization. In this post, we’ll learn how to create a custom user model in Django.

Although we can use the default user model provided by Django’s authentication module without making any changes, there can be situations in which the default user model has to be modified.

For example, you may have to add additional fields to the user model or use email instead of a username for login.

In fact, we have a couple of different ways to customize the Django user model. We mainly use these two methods.

1. AbstractUser
2. AbstractBaseUser

In this post, we’ll use AbstractBaseUser to customize the user model.

The source code of this project can be downloaded from GitHub.

Create a Django Project

Let us start by creating a new Django project.

django-admin startproject djangouser

Navigate to the project folder using:

cd djangouser

Next, we have to create a new app called accounts. This app will hold our custom user model.

python manage.py startapp accounts

Register the app under INSTALLED_APPS in settings.py.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'accounts'
]

Customize User Model With AbstractBaseUser

The AbstractBaseUser and AbstractUser classes provide the basic fields and features of a User model password filed and password hashing mechanism so that we don’t have to reinvent the wheel.

Open the models.py file of accounts and import AbstractBaseUser and BaseUserManager from django.contrib.auth.models.

Here’s the code of my models.py file.

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager
from django.contrib.auth.models import PermissionsMixin
from django.core import validators

Now, let us create our Custom User Model by creating a class named User that inherits from AbstractBaseUser.

class User(AbstractBaseUser, PermissionsMixin):

    # Primary key of the model
    id = models.BigAutoField(
        primary_key = True,
    )

    # Email field that serves as the username field
    email = models.CharField(
        max_length = 50, 
        unique = True, 
        validators = [validators.EmailValidator()],
        verbose_name = "Email"
    )

    # Other required fields for authentication
    # If the user is a staff, defaults to false
    is_staff = models.BooleanField(default=False)

    # If the user account is active or not. Defaults to True.
    # If the value is set to false, user will not be allowed to sign in.
    is_active = models.BooleanField(default=True)
    
    # Setting email instead of username
    USERNAME_FIELD = 'email'
    
    # Custom user manager
    objects = UserManager()
    
    def get_full_name(self):
        # Returns the first_name and the last_name
        return f'{self.first_name} {self.last_name}'

    def get_short_name(self):
        # Returns the short name for the user.
        return self.first_name

Note that I have not included the password field and is_superuser in this model. This is because, as I mentioned earlier, the password field will be inherited from AbstarctBaseUser class and is_superuser field will be inherited from PermissionsMixin. Also, note that we are using email instead of a username.

We can also add additional fields like First name and Last Name to the model if we want.

class User(AbstractBaseUser, PermissionsMixin):

    # Primary key of the model
    id = models.BigAutoField(
        primary_key = True,
    )

    first_name = models.CharField(
        max_length = 20,
        verbose_name = "First Name",
    )

    last_name = models.CharField(
        max_length = 20,
        verbose_name = "Last Name",
    )

    # Email field that serves as the username field
    email = models.CharField(
        max_length = 50, 
        unique = True, 
        validators = [validators.EmailValidator()],
        verbose_name = "Email"
    )

    # Other required fields for authentication
    # If the user is a staff, defaults to false
    is_staff = models.BooleanField(default=False)

    # If the user account is active or not. Defaults to True.
    # If the value is set to false, user will not be allowed to sign in.
    is_active = models.BooleanField(default=True)
    
    # Setting email instead of username
    USERNAME_FIELD = 'email'
    
    # Custom user manager
    objects = UserManager()
    
    def get_full_name(self):
        # Returns the first_name and the last_name
        return f'{self.first_name} {self.last_name}'

    def get_short_name(self):
        # Returns the short name for the user.
        return self.first_name

The default UserManager can only be used if our model contains username, email, is_staff, is_active, is_superuser, last_login, and date_joined fields. Note that we are using email instead of username and we have completely removed the username field. So, we should customize the default UserManager to make it work with our custom User Model.

In models.py, create a new UserManager above the User model.

class UserManager(BaseUserManager):
    use_in_migrations = True

    # Method to save user to the database
    def save_user(self, email, password, **extra_fields):
        """
        Creates and saves a User with the given email and password.
        """
        if not email:
            raise ValueError('The given email must be set')

        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)

        # Call this method for password hashing
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email, password=None, **extra_fields):
        extra_fields['is_superuser'] = False
        extra_fields['is_staff'] = False
        return self.save_user(email, password, **extra_fields)

    # Method called while creating a staff user
    def create_staffuser(self, email, password, **extra_fields):
        extra_fields['is_staff'] = True
        extra_fields['is_superuser'] = False
        
        return self.save_user(email, password, **extra_fields) 

    # Method called while calling creatsuperuser
    def create_superuser(self, email, password, **extra_fields):

        # Set is_superuser parameter to true
        extra_fields.setdefault('is_superuser', True)

        if extra_fields.get('is_superuser') is not True:
            raise ValueError('is_superuser should be True')
        
        extra_fields['is_staff'] = True

        return self.save_user(email, password, **extra_fields) 

The following line in the User model configures it to use our custom UserManager class.

objects = UserManager()

Here’s the complete code of my models.py file.

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager
from django.contrib.auth.models import PermissionsMixin
from django.core import validators

# Create your models here.
class UserManager(BaseUserManager):
    use_in_migrations = True

    # Method to save user to the database
    def save_user(self, email, password, **extra_fields):
        """
        Creates and saves a User with the given email and password.
        """
        if not email:
            raise ValueError('The given email must be set')

        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)

        # Call this method for password hashing
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email, password=None, **extra_fields):
        extra_fields['is_superuser'] = False
        extra_fields['is_staff'] = False
        return self.save_user(email, password, **extra_fields)

    # Method called while creating a staff user
    def create_staffuser(self, email, password, **extra_fields):
        extra_fields['is_staff'] = True
        extra_fields['is_superuser'] = False
        
        return self.save_user(email, password, **extra_fields) 

    # Method called while calling creatsuperuser
    def create_superuser(self, email, password, **extra_fields):

        # Set is_superuser parameter to true
        extra_fields.setdefault('is_superuser', True)

        if extra_fields.get('is_superuser') is not True:
            raise ValueError('is_superuser should be True')
        
        extra_fields['is_staff'] = True

        return self.save_user(email, password, **extra_fields) 
    

class User(AbstractBaseUser, PermissionsMixin):

    # Primary key of the model
    id = models.BigAutoField(
        primary_key = True,
    )

    first_name = models.CharField(
        max_length = 20,
        verbose_name = "First Name",
    )

    last_name = models.CharField(
        max_length = 20,
        verbose_name = "Last Name",
    )

    # Email field that serves as the username field
    email = models.CharField(
        max_length = 50, 
        unique = True, 
        validators = [validators.EmailValidator()],
        verbose_name = "Email"
    )

    # Other required fields for authentication
    # If the user is a staff, defaults to false
    is_staff = models.BooleanField(default=False)

    # If the user account is active or not. Defaults to True.
    # If the value is set to false, user will not be allowed to sign in.
    is_active = models.BooleanField(default=True)
    
    # Setting email instead of username
    USERNAME_FIELD = 'email'

    # Custom user manager
    objects = UserManager()

    def get_full_name(self):
        # Returns the first_name plus the last_name, with a space in between.
        return f'{self.first_name} {self.last_name}'

    def get_short_name(self):
        # Returns the short name for the user.
        return self.first_name

Now we have a customized Django user model and we have to tell Django to use this model instead of the default one. For that, add the following line to the end of settings.py

AUTH_USER_MODEL = 'accounts.User'

The last step is to commit the changes to database using:

python manage.py makemigrations
python manage.py migrate

If you previously made any migrations, you may get some errors at this point. The easiest way to solve this issue is to delete the existing database and migrations and run the above mentioned commands again.

You can test the User model by creating a new superuser using this command.

python manage.py createsuperuser

Instead of username, Django will now ask for email id and the login page of django admin dashboard will use email instead of username and password.

If you are facing, let me know in the comments below.

report this ad

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

Как правило возникает потребность хранить дополнительные данные о пользователях, например, краткую биографию (about), дату рождения, местоположение и другие подобные данные.

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

Стратегии расширения

Опишем кратко стратегии расширения пользовательской модели Django и потребности в их применении. А потом раскроем детали конфигурирование по каждой стратегии.

1. Простое расширение модели (proxy)

   Эта стратегия без создания новых таблиц в базе данных. Используется, чтобы изменить поведение существующей модели (например, упорядочение по умолчанию, добавление новых методов и т.д.), не затрагивая существующую схему базы данных.

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

2. Использование связи один-к-одному с пользовательской моделью (user profiles)

   Это стратегия с использованием дополнительной обычный модели Django со своей таблицей в базе данных, которая связана пользователем стандартной модели через связь OneToOneField.

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

3. Расширение AbstractBaseUser

   Это стратегия использования совершенно новой модели пользователя, которая отнаследована от AbstractBaseUser. Требует особой осторожности и изменения настроек в settings.py. В идеале должно быть сделано в начале проекта, так как будет существенно влиять на схему базы данных.

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

4. Расширение AbstractUser

   Это стратегия использования новой модели пользователя, которая отнаследована от AbstractUser. Требует особой осторожности и изменения настроек в settings.py. В идеале должно быть сделано в начале проекта, так как будет существенно влиять на схему базы данных.

   Вы можете использовать эту стратегию, когда сам процесс аутентификации Django вас полностью удовлетворяет и вы не хотите его менять. Тем не менее, вы хотите добавить некоторую дополнительную информацию непосредственно в модели пользователя, без необходимости создавать дополнительный класс (как в варианте 2).→

Простое расширение модели (proxy)

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

models.py

from django.contrib.auth.models import User
from .managers import PersonManager

class Person(User):
    objects = PersonManager()

    class Meta:
        proxy = True
        ordering = ('first_name', )

    def do_something(self):
        ...

В приведенном выше примере мы определили расширение модели User моделью Person. Мы говорим Django это прокси-модель, добавив следующее свойство внутри class Meta:

Proxy = True

Также в примере назначен пользовательский диспетчер модели, изменен порядок по умолчанию, а также определен новый метод do_something().

Стоит отметить, что User.objects.all() и Person.objects.all() будет запрашивать ту же таблицу базы данных. Единственное отличие состоит в поведении, которое мы определяем для прокси-модели.

Использование связи один-к-одному с пользовательской моделью (user profiles)

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

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

models.py

from django.db import models
from django.contrib.auth.models import User

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    bio = models.TextField(max_length=500, blank=True)
    location = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

Теперь добавим немножко магии: определим сигналы, чтобы наша модель Profile автоматически обновлялась при создании/изменении данных модели User.

from django.db import models
from django.contrib.auth.models import User
from django.db.models.signals import post_save
from django.dispatch import receiver

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    bio = models.TextField(max_length=500, blank=True)
    location = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

@receiver(post_save, sender=User)
def save_user_profile(sender, instance, **kwargs):
    instance.profile.save()

Мы «зацепили» create_user_profile() и save_user_profile() к событию сохранения модели User. Такой сигнал называется post_save.

А теперь пример шаблона Django с использованием данных Profile:

<h2>{{ user.get_full_name }}</h2>
<ul>
  <li>Username: {{ user.username }}</li>
  <li>Location: {{ user.profile.location }}</li>
  <li>Birth Date: {{ user.profile.birth_date }}</li>
</ul>

А еще можно вот так:

def update_profile(request, user_id):
    user = User.objects.get(pk=user_id)
    user.profile.bio = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit...'
    user.save()

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

Если вам необходимо работать с формами, то ниже приведены примеры кода для этого. Помните, что вы можете за один раз (из одной формы) обрабатывать данные более одной модели (класса).

forms.py

class UserForm(forms.ModelForm):
    class Meta:
        model = User
        fields = ('first_name', 'last_name', 'email')

class ProfileForm(forms.ModelForm):
    class Meta:
        model = Profile
        fields = ('url', 'location', 'company')

views.py

@login_required
@transaction.atomic
def update_profile(request):
    if request.method == 'POST':
        user_form = UserForm(request.POST, instance=request.user)
        profile_form = ProfileForm(request.POST, instance=request.user.profile)
        if user_form.is_valid() and profile_form.is_valid():
            user_form.save()
            profile_form.save()
            messages.success(request, _('Your profile was successfully updated!'))
            return redirect('settings:profile')
        else:
            messages.error(request, _('Please correct the error below.'))
    else:
        user_form = UserForm(instance=request.user)
        profile_form = ProfileForm(instance=request.user.profile)
    return render(request, 'profiles/profile.html', {
        'user_form': user_form,
        'profile_form': profile_form
    })

profile.html

<form method="post">
  {% csrf_token %}
  {{ user_form.as_p }}
  {{ profile_form.as_p }}
  <button type="submit">Save changes</button>
</form>

И об обещанной оптимизации запросов. В полном объеме вопрос рассмотрен в другой моей статье.

Но, если коротко, то Django отношения ленивы. Django формирует запрос к таблице базы данных, если необходимо прочитать одно из ее полей. Относительно нашего примера, эффективным будет использование метода select_related().

Зная заранее, что вам необходимо получить доступ к связанным данным, вы можете c упреждением сделать это одним запросом:

users = User.objects.all().select_related('Profile')

Расширение AbstractBaseUser

Если честно, я стараюсь избегать этот метод любой ценой. Но иногда это не возможно. И это прекрасно. Едва ли существует такая вещь, как лучшее или худшее решение. По большей части, существует более или менее подходящее решение. Если это является наиболее подходящим решением для вас, что ж — идите вперед.

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

Мне нужно было использовать адрес электронной почты в качестве auth token, а username абсолютно был не нужен. Кроме того, не было никакой необходимости флага is_staff, так как я не использовал Django Admin.

Вот как я определил свою собственную модель пользователя:

from __future__ import unicode_literals

from django.db import models
from django.contrib.auth.models import PermissionsMixin
from django.contrib.auth.base_user import AbstractBaseUser
from django.utils.translation import ugettext_lazy as _

from .managers import UserManager


class User(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(_('email address'), unique=True)
    first_name = models.CharField(_('first name'), max_length=30, blank=True)
    last_name = models.CharField(_('last name'), max_length=30, blank=True)
    date_joined = models.DateTimeField(_('date joined'), auto_now_add=True)
    is_active = models.BooleanField(_('active'), default=True)
    avatar = models.ImageField(upload_to='avatars/', null=True, blank=True)

    objects = UserManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = []

    class Meta:
        verbose_name = _('user')
        verbose_name_plural = _('users')

    def get_full_name(self):
        '''
        Returns the first_name plus the last_name, with a space in between.
        '''
        full_name = '%s %s' % (self.first_name, self.last_name)
        return full_name.strip()

    def get_short_name(self):
        '''
        Returns the short name for the user.
        '''
        return self.first_name

    def email_user(self, subject, message, from_email=None, **kwargs):
        '''
        Sends an email to this User.
        '''
        send_mail(subject, message, from_email, [self.email], **kwargs)

Я хотел сохранить ее как можно ближе к «стандартной» модели пользователя. Отнаследовав от AbstractBaseUser мы должны следовать некоторым правилам:

• USERNAME_FIELD — строка с именем поля модели, которая используется в качестве уникального идентификатора (unique=True в определении);
• REQUIRED_FIELDS — список имен полей, которые будут запрашиваться при создании пользователя с помощью команды управления createsuperuser
• is_active — логический атрибут, который указывает, считается ли пользователь «активным»;
• get_full_name() — длинное описание пользователя: не обязательно полное имя пользователя, это может быть любая строка, которая описывает пользователя;
• get_short_name() — короткое описание пользователя, например, его имя или ник.

У меня был также собственный UserManager. Потому что существующий менеджер определяет create_user() и create_superuser() методы.

Мой UserManager выглядел следующим образом:

from django.contrib.auth.base_user import BaseUserManager

class UserManager(BaseUserManager):
    use_in_migrations = True

    def _create_user(self, email, password, **extra_fields):
        """
        Creates and saves a User with the given email and password.
        """
        if not email:
            raise ValueError('The given email must be set')
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email, password=None, **extra_fields):
        extra_fields.setdefault('is_superuser', False)
        return self._create_user(email, password, **extra_fields)

    def create_superuser(self, email, password, **extra_fields):
        extra_fields.setdefault('is_superuser', True)

        if extra_fields.get('is_superuser') is not True:
            raise ValueError('Superuser must have is_superuser=True.')

        return self._create_user(email, password, **extra_fields)

По сути, я очистил существующий UserManager от полей username и is_staff.

Последний штрих. Необходимо изменить settings.py:

AUTH_USER_MODEL = 'core.User'

Таким образом, мы говорим Django использовать нашу пользовательскую модель вместо поставляемой «в коробке». В примере выше, я создал пользовательскую модель внутри приложения с именем core.

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

Есть два способа. Рассмотрим модель под названием Course:

from django.db import models
from testapp.core.models import User

class Course(models.Model):
    slug = models.SlugField(max_length=100)
    name = models.CharField(max_length=100)
    tutor = models.ForeignKey(User, on_delete=models.CASCADE)

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

from django.db import models
from django.conf import settings

class Course(models.Model):
    slug = models.SlugField(max_length=100)
    name = models.CharField(max_length=100)
    tutor = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)

Расширение AbstractUser

Это довольно просто, поскольку класс django.contrib.auth.models.AbstractUser обеспечивает полную реализацию пользовательской модели по-умолчанию в качестве абстрактной модели.

from django.db import models
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    bio = models.TextField(max_length=500, blank=True)
    location = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

После этого необходимо изменить settings.py:

AUTH_USER_MODEL = 'core.User'

Как и в предыдущей стратегии, в идеале это должно быть сделано в начале проекта и с особой осторожностью, посколько изменит всю схему базы данных. Также хорошим правилом будет создавать ключи к пользовательской модели через импорт настроек from django.conf import settings и использования settings.AUTH_USER_MODEL вместо непосредственной ссылки на класс User.

Резюме

Отлично! Мы рассмотрели четыре различных стратегии расширения «стандартной» пользовательской модели. Я попытался сделать это как можно более подробно. Но, как я уже говорил, лучшего решения не существует. Все будет зависеть от того, что вы хотите получить.

• Простое расширение модели (proxy) — вас устраивает процесс аутентификации и хранение данных пользователя, вам просто хотелось бы изменить некоторое поведение.
• Использование связи один-к-одному с пользовательской моделью (user profiles) — вас устраивает процесс аутентификации, но хотелось бы добавить дополнительные данные пользователя (данные будут хранится в специальной модели).
• Расширение AbstractBaseUser — процесс аутентификации «из коробки» вам не подходит.
• Расширение AbstractUser — вас устраивает процесс аутентификации, но хотелось бы добавить дополнительные данные пользователя (данные будут хранится непосредственно в пользовательской модели, а не в специальной модели).