Dica 14 - Django Custom User com e-mail
Versões usadas no vídeo: Django 4.1.3, Python 3.10 e PostgreSQL 14 (no Docker).
Código: https://github.com/rg3915/dicas-de-django (branch aula14)
Por padrão, o Django autentica com username e senha. Neste tutorial vamos trocar o model de usuário por um usuário customizado que usa o e-mail no lugar do username: no createsuperuser, no admin e, na próxima dica, no login. Faremos isso estendendo AbstractBaseUser, com um manager próprio, um admin próprio e testes.
Esta dica continua o Projeto Dicas de Django da Dica 13 - Dashboard com Django e Tailwind CSS. O mesmo assunto já tinha aparecido num vídeo anterior do canal, citado abaixo.
User, AbstractUser ou AbstractBaseUser?
Vale olhar o código-fonte do Django para entender de onde vem cada campo (links para o código do Django usado como referência no vídeo):
User
AbstractUser
AbstractBaseUser
Useré só uma subclasse deAbstractUser, sem nada a mais.AbstractUser(que herda deAbstractBaseUserePermissionsMixin) defineusername(obrigatório e único),first_name,last_name,email,is_staff,is_activeedate_joined.AbstractBaseUsertem só o essencial da autenticação:password,last_logine os métodos de senha.
Como não queremos o campo username, e sim o e-mail no lugar dele, não dá para herdar de AbstractUser. Vamos herdar de AbstractBaseUser (e de PermissionsMixin, que traz is_superuser, grupos e permissões) e declarar nós mesmos os campos que queremos.
O código foi baseado neste artigo do Simple is Better Than Complex:
Extending User Model Using a Custom Model Extending AbstractBaseUser
E no vídeo anterior do canal sobre o mesmo assunto:
Django autenticação e login com email - Django login email
Criando a app accounts
git checkout -b aula14
cd backend
python ../manage.py startapp accounts
cd ..
touch backend/accounts/managers.py
Como a app fica dentro da pasta backend, ajuste o name no apps.py (o startapp gera só 'accounts'):
# backend/accounts/apps.py
from django.apps import AppConfig
class AccountsConfig(AppConfig):
default_auto_field = 'django.db.models.BigAutoField'
name = 'backend.accounts'
Configurando o settings
Duas mudanças no settings.py:
AUTH_USER_MODEL = 'accounts.User'diz ao Django que o model de usuário do projeto é oUserda appaccounts(o formato érótulo_da_app.Model, e o rótulo da app éaccounts, nãobackend.accounts).- a app
backend.accountsentra noINSTALLED_APPSantes dodjango.contrib.admin.
# backend/settings.py
ALLOWED_HOSTS = config('ALLOWED_HOSTS', default=[], cast=Csv())
AUTH_USER_MODEL = 'accounts.User'
# Application definition
INSTALLED_APPS = [
'backend.accounts', # <<<
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
# apps de terceiros
'django_extensions',
# minhas apps
'backend.core',
'backend.crm',
]
O model User
# backend/accounts/models.py
# ... (veja o arquivo completo no GitHub)
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(_('email address'), unique=True)
first_name = models.CharField(_('first name'), max_length=150, blank=True)
last_name = models.CharField(_('last name'), max_length=150, blank=True)
date_joined = models.DateTimeField(_('date joined'), auto_now_add=True)
is_active = models.BooleanField(_('active'), default=True)
is_admin = models.BooleanField(
_('admin status'),
default=False,
help_text=_(
'Designates whether the user can log into this admin site.'),
)
objects = UserManager()
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = []
class Meta:
verbose_name = _('user')
verbose_name_plural = _('users')
def __str__(self):
return self.email
def has_perm(self, perm, obj=None):
"Does the user have a specific permission?"
# Simplest possible answer: Yes, always
return True
def has_module_perms(self, app_label):
"Does the user have permissions to view the app `app_label`?"
# Simplest possible answer: Yes, always
return True
# ... (veja o arquivo completo no GitHub)
@property
def is_staff(self):
"Is the user a member of staff?"
# Simplest possible answer: All admins are staff
return self.is_admin
Código completo: backend/accounts/models.py
O que importa aqui:
emailéunique=True, porque vai ser o identificador do usuário.USERNAME_FIELD = 'email'diz ao Django que o campo usado como "nome de usuário" (no login, nocreatesuperuser, noauthenticate) é o e-mail.REQUIRED_FIELDS = []: campos extras que ocreatesuperuserpede além doUSERNAME_FIELDe da senha. Nenhum.is_adminfaz o papel dois_staffdo Django: em vez de um campois_staff, existe a propertyis_staff, que devolveis_admin. É ela que o admin consulta para deixar o usuário entrar.has_permehas_module_permsdevolvem sempreTrue, a resposta mais simples possível, como no artigo de referência. Na prática, quem decide se o usuário entra no admin é ois_staff(ou seja, ois_admin). Repare que esses dois métodos substituem os doPermissionsMixin, então as permissões por grupo não são verificadas.get_full_name,get_short_nameeemail_usersão os mesmos métodos que oUserpadrão tem.objects = UserManager()é o manager que vamos escrever a seguir.
O manager
O BaseUserManager padrão não sabe criar usuário sem username, então escrevemos o nosso, com create_user e create_superuser recebendo o e-mail:
# backend/accounts/managers.py
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_admin', True)
extra_fields.setdefault('is_superuser', True)
if extra_fields.get('is_admin') is not True:
raise ValueError('Superuser must have is_admin=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)
_create_usernormaliza o e-mail (deixa o domínio em minúsculas), grava a senha comset_password(que guarda o hash, nunca a senha pura) e salva.create_superuserligais_admineis_superusere confere se os dois ficaramTrue.use_in_migrations = Truefaz o manager entrar nas migrations (por isso a migration gerada importabackend.accounts.managers).
O admin
O UserAdmin do Django faz referência a campos do auth.User (como username e is_staff), então criamos o nosso, herdando dele e redefinindo os campos:
# backend/accounts/admin.py
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin as BaseUserAdmin
from django.utils.translation import gettext_lazy as _
from .models import User
class UserAdmin(BaseUserAdmin):
# The fields to be used in displaying the User model.
# These override the definitions on the base UserAdmin
# that reference specific fields on auth.User.
list_display = ('email', 'first_name', 'last_name', 'is_admin', 'is_active') # noqa E501
list_filter = ('is_admin',)
fieldsets = (
(None, {'fields': ('email', 'password')}),
(_('Personal info'), {'fields': ('first_name', 'last_name')}),
(_('Permissions'), {
'fields': (
'is_active',
'is_admin',
# 'is_superuser',
'groups',
'user_permissions',
)
}),
(_('Important dates'), {'fields': ('last_login',)}),
)
# add_fieldsets is not a standard ModelAdmin attribute. UserAdmin
# overrides get_fieldsets to use this attribute when creating a user.
add_fieldsets = (
(None, {
'classes': ('wide',),
'fields': ('email', 'password1', 'password2'),
}),
)
search_fields = ('email', 'first_name', 'last_name')
ordering = ('email',)
filter_horizontal = ('groups', 'user_permissions',)
admin.site.register(User, UserAdmin)
fieldsetssão os grupos de campos da tela de edição.add_fieldsetsé usado só na tela de criação de usuário: e-mail, senha e confirmação da senha.orderingesearch_fieldsusam o e-mail no lugar do username (oUserAdminpadrão ordena porusername, que não existe mais).
Os testes
# backend/accounts/tests.py
from django.test import TestCase
from backend.accounts.models import User
class TestUser(TestCase):
def setUp(self):
self.user = User.objects.create_user(
email='admin@email.com',
password='demodemo',
first_name='Admin',
last_name='Admin',
)
self.superuser = User.objects.create_superuser(
email='superadmin@email.com',
password='demodemo'
)
def test_user_exists(self):
self.assertTrue(self.user)
def test_str(self):
self.assertEqual(self.user.email, 'admin@email.com')
# ... (veja o arquivo completo no GitHub)
Código completo: backend/accounts/tests.py
Migrations: o erro InconsistentMigrationHistory
Gere a migration e aplique:
python manage.py makemigrations
Migrations for 'accounts':
backend/accounts/migrations/0001_initial.py
- Create model User
python manage.py migrate
Como o banco já tinha as migrations do projeto aplicadas com o auth.User padrão (o migrate foi rodado nas dicas anteriores), o Django reclama:
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency accounts.0001_initial on database 'default'.
A migration do admin depende do model de usuário (AUTH_USER_MODEL), e agora esse model está na accounts.0001_initial, que nunca foi aplicada. Trocar o model de usuário com o banco já criado não é simples, e é por isso que a recomendação é definir o usuário customizado no início do projeto. Como aqui ainda não temos dados que importam, a solução é apagar o banco e criar de novo.
No projeto, o PostgreSQL roda no Docker (veja a Dica 7). Remova o contêiner do banco e o volume:
docker container rm dicas_de_django_db -f
docker volume prune -f
Deleted Volumes:
dicas-de-django_pgdata
Total reclaimed space: 52.89MB
Atenção: o docker volume prune -f remove todos os volumes que não estão em uso por nenhum contêiner, não só o deste projeto.
Suba o banco de novo (no projeto existe o comando make up, que roda docker-compose up -d, criado na Dica 10) e rode as migrations:
make up
python manage.py migrate
Operations to perform:
Apply all migrations: accounts, admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0001_initial... OK
...
Applying auth.0012_alter_user_first_name_max_length... OK
Applying accounts.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying sessions.0001_initial... OK
Criando o superusuário
Agora o createsuperuser pede o e-mail direto, sem username:
python manage.py createsuperuser --email="admin@email.com"
Sem o --email, ele pergunta Endereço de email:. No vídeo foi usada uma senha bem simples, então o Django avisou que ela é curta e comum, e perguntou se queria criar assim mesmo (Bypass password validation and create user anyway? [y/N]: y).
Rodando os testes
python manage.py test
Found 12 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
............
----------------------------------------------------------------------
Ran 12 tests in 3.282s
OK
Destroying test database for alias 'default'...
Conferindo no admin
Rode o servidor, entre em http://localhost:8000/admin/ com o e-mail e a senha do superusuário e abra Usuários > Adicionar: o formulário pede apenas Endereço de email, Senha e Confirmação de senha.
Pronto: o projeto agora usa e-mail e senha no lugar de username e senha. Na próxima dica, Dica 15 - Login com e-mail no Django, fazemos a tela de login.