Python on Renne Rocha

Extending built-in Django User with a custom Model

blog@rocha.dev.br (Renne Rocha) — Mon, 01 May 2023 19:28:40 -0300

The user authentication system provided by Django is extremely powerful and handles most of the authentication (Am I who I say I am?) and authorization (Am I authorized to do what I want to do?) needs of an web project. User accounts, groups and permissions, methods for handling passwords securely are part of this system.

Generally, this is adequate for most projects; however, there are situations where it becomes necessary to modify the behavior of a User or alter how their data is stored in the database. It should be noted that modifying the authorization and/or authentication process of a User will not be covered in this post.

Creating a user profile model is one solution to extend and modify the behavior of a User, as discussed before, but that approach has some caveats that are solved with the use of a custom user model.

Custom User model

We can tell Django which is the model that will replace the built-in django.contrib.auth.models.User model in the system. This is done by providing a value to AUTH_USER_MODEL in your project.

1
2

# myproject/myproject/settings.py
AUTH_USER_MODEL = "users.CustomUser"

Usually I create a users application to group all custom user related code to keep everything in the same context

It is highly recommended that you do this configuration at the beginning of the project, as after you have created your database tables, it will require you to fix your schema, moving data between tables and reapplying some migrations manually (see #25313 for an overview of the steps involved).

Now we need to create our custom model.

This new user model can handle different authentication and authorization schemes, can use different fields (e.g. email) to identify the user or any other requirement that is not satisfied using the default Django user model.

Adding new fields to default User model

If the default User model has everything we need and we want to add some extra profile fields keeping authentication and authorization as it is, create a custom model inheriting from AbstractUser would be enough.

# myproject/users/models.py
from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    date_of_birth = models.DateField(null=True)

1
2

# myproject/myproject/settings.py
AUTH_USER_MODEL = "users.CustomUser"

As we will not create a new table to store the user related information, there is no need for additional database queries to retrieve related models. We also don’t need to worry if a related model is created or not reducing the complexity of the system.

AbstractBaseUser

If we want to use a different field as the identifier (other than email), use a different authorization system and/or having more control on what fields we have in our user model, a custom model inheriting from AbstractBaseUser is the choice.

AbstractBaseUser is the core implementation of a User. It has a password field and methods to store and validate it securely. A last_login datetime field and everything else is up to us to provide.

If using the default authentication backend, our model must have a single unique field that will be the identifier of our user such as email address, username or any other unique attribute.

You configure that attribute using USERNAME_FIELD that defines what is the field that will uniquely identify the user.

EMAIL_FIELD

REQUIRED_FIELDS

is_active is an attribute on AbstractBaseUser defaulting to True

As an example, we will define a custom user that will use the email address as the identifier, has the date of birth as one required field can store the phone number and has a flag field in the database to indicate if the user is active or not.

# myproject/users/models.py
from django.contrib.auth.models import AbstractBaseUser

class CustomUser(AbstractBaseUser):
    USERNAME_FIELD = "email"
    EMAIL_FIELD = "email"
    REQUIRED_FIELDS = ["date_of_birth", ]

    date_of_birth = models.EmailField(unique=True)
    email = models.EmailField(unique=True)
    is_active = models.BooleanField(default=True)
    phone_number = models.CharField(max_length=16, blank=True)

FROM DOCS Authentication backends provide an extensible system for when a username and password stored with the user model need to be authenticated against a different service than Django’s default.

TODO: list all fields that are created with this

Any other fields needs to be created.

is_active is a property set to True, but you can define if you want

USERNAME_FIELD is needed identifier unique = True EMAIL_FIELD to specifi what is the email field REQUIRED_FIELDS fields required when createsuperuser

If we want to use email as the identifier of an user, we need to set USERNAME_FIELD property

# myproject/users/models.py
class CustomUser(AbstractBaseUser):
    USERNAME_FIELD = "email"

    email = models.EmailField()

One drawback is you need to specify a Custom Manager implementing two methods: create_user and create_superuser. This is required so we willll be able to run python manage.py createsuperuser and python manage.py create-user.

If some fields (TODO list what fields) from ABstractUser are there, you can use the built-in UserManager FROM DOCS username, email, is_staff, is_active, is_superuser, last_login, and date_joined fields the same as Django’s default user, you can install Django’s UserManager

# myproject/users/models.py
class CustomUser(AbstractBaseUser):
    USERNAME_FILED = "email"

    email = models.EmailField()

    objects = UserManager()

If you don’t want to use Django Admin (very unlikely), you’re done, and you can create/manage your users and authentication backend will be able.

However, if you want to use this custom user model with Django admin, there are some extra steps.

We need some fields and methods: is_staff so you have access to django admin is_active inactive users can’t access django admin

to manage permissions to edit registered models has_perm has_module_perms() we don’t need to use the built-in permission system (see PermissionMixin)

And UserCreationForm< UserChangeForm and PasswordResetForm (if we don’t have email field) needs to be customized so we can use that.

Also we need a custom UserAdmin to use our custom forms.

This is a lot of things, and sometimes difficult to remember. The docs are ok to describe the process, but IMO this should be much simpler :-P

If by any chance you want to use django model permission, you can use PermissionMixin, so you have access to groups, etc (to be honest, I never saw anything using permission, but groups)

Sometimes the username may not be the way you want to identify an user (an email or social number would be more suitable for your project) or we have different requirements for authorization and permission. In those cases creating a custom user model is a option.

This has advatanges over the user of a user profile model and solve some of the caveats of that approach such as:

We won’t need an extra database table to store your custom fields, so there is no performance problems to access them;
As the table that we store the User data required for Django authentication is the same, we don’t need to bother if your profile fields will be available or not

When creating a custom user model, we have two different options If you are going to this path, you can create your custom user inheriting from two different classes:

If using Django Admin, we also need to register this new model.

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

admin.site.register(CustomUser, UserAdmin)

Extending built-in Django User with a Profile Model

blog@rocha.dev.br (Renne Rocha) — Mon, 24 Apr 2023 19:28:40 -0300

For the people that prefers video content you can also watch me explaining the content of this post in the following video (but in Portuguese):

Extending with an extra Model

The simplest way to extend your User is to create a new model with a OneToOneField relation to the default User model. This model will contain all extra fields that extends your User.

If we are satisfied by the default of Django User model and just want to add extra fields (like a user profile), this is the easiest and simpler solution.

As an example, to create a user profile storing the date of birth and phone number of a User we could use the model:

# myproject/userprofile/models.py
from django.db import models

class Profile(models.Model):
    user = models.OneToOneField(
        "auth.User", on_delete=models.CASCADE, related_name="profile"
    )
    date_of_birth = models.DateField(null=True)
    phone_number = models.CharField(max_length=32, blank=True)

    def __str__(self):
        return f"Profile of '{self.user.username}'"

However there are some caveats with this approach that we need to keep in mind to avoid unexpected issues such as:

A new table is created, so retrieving data from both tables will require more queries;
- The use of the select_related function can resolve performance issues caused by the new table. However, if we overlook this aspect, we may encounter unforeseen problems;
A Profile instance is not created automatically when you create a new User. We can solve this with a post_save signal handler;
- When multiple users are created simultaneously using the bulk_create method, post_save is not triggered, which may result in users being created without a Profile.
We need to do some extra work if we want to have these fields added to the User details in Django Admin

To create a new Profile when a new User is created we need to catch post_save signal:

# myproject/userprofile/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User

from userprofile.models import Profile

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, *args, **kwargs):
    # Ensure that we are creating an user instance, not updating it
    if created:
        Profile.objects.create(user=instance)

# myproject/userprofile/apps.py
from django.apps import AppConfig

class UserprofileConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "userprofile"

    def ready(self):
        # Register your signal here, so it will be imported once
        # when the app is ready
        from userprofile import signals  # noqa

Running the application, we will ensure that every time we create a new User, a related Profile will be created as well:

In [1]: from django.contrib.auth.models import User
   ...: from userprofile.models import Profile

In [2]: Profile.objects.all()
Out[2]: <QuerySet []>

In [3]: user = User.objects.create(username="myuser", email="email@myuser.com")

In [4]: Profile.objects.all()
Out[4]: <QuerySet [<Profile: Profile of 'myuser'>]>

As mentioned before, when creating instances in bulk, the signal will not be emited, so the Profile will not be automatically created:

In [5]: users = User.objects.bulk_create(
   ...:     [
   ...:         User(username="First user", email="user1@user1.com"),
   ...:         User(username="Second user", email="user2@user2.com"),
   ...:     ]
   ...: )

In [6]: users
Out[6]: [<User: First user>, <User: Second user>]

In [7]: Profile.objects.all()
Out[7]: <QuerySet [<Profile: Profile of 'myuser'>]>

One limitation of this approach is that we are not allowed to have required fields in the user profile without providing a default value.

As an example, if we require that date_of_birth is mandatory and our Profile model is like the following:

# myproject/userprofile/models.py
from django.db import models

class Profile(models.Model):
    user = models.OneToOneField(
        "auth.User", on_delete=models.CASCADE, related_name="profile"
    )
    date_of_birth = models.DateField()  # date_of_birth IS REQUIRED
    phone_number = models.CharField(max_length=32, blank=True)

    def __str__(self):
        return f"Profile of '{self.user.username}'"

When creating a new user, our post_save handler will fail:

In [1]: from django.contrib.auth.models import User
   ...: from userprofile.models import Profile

In [2]: user = User.objects.create(username="myuser", email="email@myuser.com")
---------------------------------------------------------------------------
IntegrityError                            Traceback (most recent call last)
(...)
IntegrityError: NOT NULL constraint failed: userprofile_profile.date_of_birth

Keeping in mind these caveats, extending the User model through this method is a simple and efficient solution that can meet the needs of many web applications.

Testando múltiplas chamadas de uma função com mocks

blog@rocha.dev.br (Renne Rocha) — Mon, 07 Nov 2022 00:00:00 +0000

Em algumas situações durante o teste e alguma função, queremos confirmar que uma determinada função foi chamada uma quantidade de vezes esperada e também com os argumentos corretos.

Isso pode ser obtido utilizando o mock da biblioteca padrão do Python ou, caso estejamos utilizando o pytest, com o auxílio da biblioteca pytest-mock.

Como exemplo, vamos testar a função main() a seguir. Ela obtém uma lista de URLs que neste exemplo é fixa, mas em um caso real, ela pode ser o resultado de uma condição especial do sistema que você está testando.

# app.py
import requests

def do_something_with_response(response):
    ...

def get_urls_to_call():
    return [
        "http://www.url1.com",
        "http://www.url2.com",
    ]

def main():
    urls_to_call = get_urls_to_call()
    for url in urls_to_call:
        response = requests.post(url)
        do_something_with_response(response)

Meu objetivo aqui é verificar se requests.post() foi chamado apenas duas vezes e se nessas duas vezes, passamos como argumento o valor das duas URLs retornadas pela função get_urls_to_call().

O primeiro passo é criar um patch de requests.post. Fazemos isso da seguinte maneira:

1
2
3

# test_app.py
def test_assert_called_with_all_urls(mocker):
    requests_post_mock = mocker.patch("app.requests.post")

A partir desse momento, qualquer chamada de requests.post dentro do módulo app será uma chamada a um MagicMock e não a função original. Atente-se que o patch não é realizado com requests.post e sim com app.requests.post.

Para mais detalhes sobre como usar corretamente a função patch, assista esta apresentação de Lisa Roach na PyCon 2018.

Em seguida podemos fazer a chamada na função que estamos testando:

# test_app.py
from app import main

def test_assert_called_with_all_urls(mocker):
    requests_post_mock = mocker.patch("app.requests.post")

    main()

mocker é apenas uma fixture do pytest-mock auxiliar de unittest.mock.

E agora iremos verificar as chamadas que foram realizadas e se or argumentos passados foram os corretos:

from app import main

def test_assert_called_with_all_urls(mocker):
    requests_post_mock = mocker.patch("app.requests.post")

    main()

    # Garante que 'requests.post' foi chamado duas vezes
    # e cada uma delas a URL correta foi passada como argumento
    requests_post_mock.assert_has_calls(
        [
            mocker.call("http://www.url1.com"),
            mocker.call("http://www.url2.com"),
        ]
    )

Existem outras validações possível, como por exemplo verificarmos se requests.post foi chamado uma única vez (assert_called_once) ou mesmo se a função não foi chamada nenhuma vez (assert_not_called) o que pode ser útil para testar condições de erro.

Só é preciso tomar cuidado para não abusar desse tipo de teste, já que ele é altamente acoplado a implementação do seu código e dependendo de como ele é definido e colocado no seu projeto, eventualmente ele pode não testar adequadamente o que você quer testar.

Revisão de Código: Extraindo dados do site 'Aos Fatos'

blog@rocha.dev.br (Renne Rocha) — Fri, 08 Apr 2022 00:00:00 +0000

Algumas semanas atrás, fiz a revisão de um código para extrair informações de campeonatos da CBF.

A experiência de fazer isso em uma live foi muito boa, pois consegui ajudar alguém compartilhando um pouco da minha experiência, mas também foi uma maneira de eu aprender mais, já que para comentar sobre algum assunto eu precisei ler e estudar (e relembrar) algumas coisas que já fazia algum tempo que eu não olhava.

Depois de algum tempo, encontrei outra pessoa que me autorizou a fazer essa revisão em uma live. Dessa vez, fiz a revisão do código que extraia informações de notícias do Aos Fatos.

O código é um projeto feito com o Scrapy, um framework Python para o desenvolvimento de raspadores de dados.

Se você quiser que eu faça uma revisão do seu código em um vídeo, é só entrar em contato comigo. Se eu achar que consigo ajudar de alguma maneira, combinamos uma nova transmissão.

Links de Referência

black - formatador de código automático
CrawlSpider - tipo de Spider que ajuda a escrever códigos mais organizados
dateparser - biblioteca para conversão de texto em data
LinkExtractor - class que auxilia a extração de links dentro de um HTML
Laboratório Hacker de Campinas - hackerspace localizado em Campinas
owncast - plataforma self-hosted por onde fiz a transmissão
PeerTube - plataforma de vídeos livre, decentralizada e federada
Meu PeerTube - instância do PeerTube onde armazeno todos os meus vídeos

Monitorando seus projetos de raspagem de dados

blog@rocha.dev.br (Renne Rocha) — Thu, 13 Jan 2022 00:00:00 +0000

Quando passamos a extrair dados de uma página com regularidade, com uma quantidade grande de dados, é muito importante monitorar a saúde dos seus raspadores e a qualidade das informações extraídas.

As páginas podem mudar (as vezes sutilmente), medidas anti-bot podem ser adicionadas e outros problemas temporários e inesperados podem ocorrer e, caso estejamos tratando de uma quantidade grande de scripts retornando milhares de itens, é praticamente impossível monitorar manualmente todo o nosso projeto.

Deste modo, devemos adicionar em nosso projeto, ferramentas que auxiliem no monitoramento.

Spidermon

O Scrapy é um dos principais frameworks para raspagem de dados em Python possuindo diversas bibliotecas e ferramentas que facilitam a criação de projetos de raspagem de dados.

O Spidermon é uma extensão do Scrapy que podemos adicionar ao nosso projeto para facilitar o monitoramento da execução dos seus spiders (como são chamados os scripts que realizam a extração de dados).

Com ela, é possível definir validar dados retornados, monitorar as estatísticas da execução (jobs) de seu spider e, a partir do resultadodessas validações, tomar ações como enviar notificações, gerar relatórios, abrir chamados em sistemas externos quando algo não esteja funcionando corretamente de uma maneira extensível.

O Spidermon pode ser instalado com o pip:

`1`	`pip install spidermon`

Uma vez instalado, precisamos habilitá-lo em nosso projeto Scrapy:

# myproject/settings.py
SPIDERMON_ENABLED = True
EXTENSIONS = {
    "spidermon.contrib.scrapy.extensions.Spidermon": 500,
}

Feito isso, podemos começar a pensar no que será monitorado.

Monitores

É no monitor onde a maioria das validações são definidas. Nele temos acesso as estatísticas e informações das execuções de nossos spiders e podemos definir as nossas regras de monitoramento.

Esse monitor precisa estar dentro de uma suíte de monitores, além de definir um conjunto de ações que devem ser executadas após a execução deles.

Como exemplo, queremos monitorar o número de mensagens de erro emitidas durante os nossos jobs. Isso pode ser feito verificando se o valor dentro da estatística log_count/ERROR é menor a um determinado valor que podemos, por exemplo, definir no arquivo de configuração do nosso projeto.

Um monitor que realiza essa tarefa pode ser definido como:

# myproject/monitors.py
from spidermon import Monitor

class JobErrorsMonitor(Monitor):
    def test_error_count(self):
        num_errors = self.data.stats.get("log_count/ERROR")
        num_errors_threshold = self.data.crawler.settings.getint(
            "MAX_NUM_ERRORS", 0
        )
        if num_errors:
            self.assertTrue(
                num_errors <= num_errors_threshold,
                msg=f"No more than {num_errors_threshold} allowed."
            )

Porém, só definir o monitor não é o suficiente para que esse teste seja rodado ao final da execução do seu spider. Precisamos adicioná-lo a uma suíte de monitores:

# myproject/monitors.py
from spidermon import Monitor, MonitorSuite

class JobErrorsMonitor(Monitor):
    # (...) O código do nosso monitor

class SpiderCloseMonitorSuite(MonitorSuite):
    monitors = [
        JobErrorsMonitor,
    ]

E definir o momento em que momento a suíte será executada, além do nosso valor de referência com o limite da quantidade de erros que aceitamos. Nesse caso, quando o spider terminar sua execução as verificações será feita.

# myproject/settings.py
SPIDERMON_ENABLED = True
EXTENSIONS = {
    "spidermon.contrib.scrapy.extensions.Spidermon": 500,
}
SPIDERMON_SPIDER_CLOSE_MONITORS = (
    "myproject.monitors.SpiderCloseMonitorSuite",
)
MAX_NUM_ERRORS = 10

Ao executar spider podemos ver os resultados desse monitor nos nossos logs:

[scrapy.core.engine] INFO: Closing spider (finished)
[myproject] INFO: [Spidermon] ---------------------- MONITORS ----------------------
[myproject] INFO: [Spidermon] JobErrorsMonitor/test_error_count... OK
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] INFO: [Spidermon] 1 monitor in 0.000s
[myproject] INFO: [Spidermon] OK
[myproject] INFO: [Spidermon] ------------------ FINISHED ACTIONS ------------------
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] INFO: [Spidermon] 0 actions in 0.000s
[myproject] INFO: [Spidermon] OK
[myproject] INFO: [Spidermon] ------------------- PASSED ACTIONS -------------------
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] INFO: [Spidermon] 0 actions in 0.000s
[myproject] INFO: [Spidermon] OK
[myproject] INFO: [Spidermon] ------------------- FAILED ACTIONS -------------------
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] INFO: [Spidermon] 1 action in 0.000s
[myproject] INFO: [Spidermon] OK (skipped=1)

Ou caso aconteça um erro:

[scrapy.core.engine] INFO: Closing spider (finished)
[myproject] INFO: [Spidermon] ---------------------- MONITORS ----------------------
[myproject] INFO: [Spidermon] JobErrorsMonitor/test_error_count... FAIL
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] ERROR: [Spidermon]
======================================================================
FAIL: JobErrorsMonitor/test_error_count
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/renne/projects/rennerocha/spidermon/examples/tutorial/tutorial/monitors.py", line 44, in test_error_count
    self.assertTrue(
AssertionError: False is not true : No more than 10 errors allowed.

[myproject] INFO: [Spidermon] 1 monitor in 0.001s
[myproject] INFO: [Spidermon] FAILED (failures=1)
[myproject] INFO: [Spidermon] ------------------ FINISHED ACTIONS ------------------
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] INFO: [Spidermon] 0 actions in 0.000s
[myproject] INFO: [Spidermon] OK
[myproject] INFO: [Spidermon] ------------------- PASSED ACTIONS -------------------
[myproject] INFO: [Spidermon] ------------------------------------------------------
[myproject] INFO: [Spidermon] 0 actions in 0.000s
[myproject] INFO: [Spidermon] OK
[myproject] INFO: [Spidermon] ------------------- FAILED ACTIONS -------------------

Simplificando o nosso monitor

Grande parte dos monitores que precisamos, verifica o valor de uma estatística do seu job com um valor pré-determinado. Por isso, podemos usar a classe BaseStatMonitor com um conjunto definido de atributos para simplificar o nosso código.

O mesmo monitor anterior, verificando se o valor de log_count/ERROR é menor ou igual ao valor definido em MAX_NUM_ERRORS nas configurações do projeto pode ser definido como:

# myproject/monitors.py
from spidermon.contrib.scrapy.monitors import BaseStatMonitor

class JobErrorsMonitor(BaseStatMonitor):
    stat_name = "log_count/ERROR"
    threshold_setting = "MAX_NUM_ERRORS"
    assert_type = "<="

O resultado da execução desse monitor é o mesmo do anterior, porém com um código muito mais simples.

Tornando o monitor mais dinâmico

Não precisamos nos restringir a testes de um valor nas estatísticas em relação a um valor estático definido nas configurações do projeto.

Para isso, ao invés de definir um valor para o atributo threshold_setting, podemos definir o método get_threshold que deverá retornar o valor que será usado como referência para o nosso monitor.

Isso é muito útil por exemplo, quando queremos verificar mais de uma estatística para definir o nosso valor de referência. No exemplo anterior, definimos uma valor fixo aceitável de mensagens de erro durante a execução do nosso spider. Porém termos 10 erros em uma execução que retorna 100k itens (0.001%) pode ser mais aceitável por exemplo do que 10 erros em uma execução que retornou 1k itens (1%).

Então podemos melhoramos o nosso monitor de erros, considerando além da quantidade de erros, a quantidade de itens retornados. Desse modo só haverá falha se o número de erros for menor do que 0.001% da quantidade de itens retornados.

# myproject/monitors.py
from spidermon.contrib.scrapy.monitors import BaseStatMonitor

class JobErrorsMonitor(BaseStatMonitor):
    stat_name = "log_count/ERROR"
    assert_type = "<="

    def get_threshold(self):
        item_scraped_count = self.data.stats.get(
            "item_scraped_count"
        )
        return item_scraped_count * 0.0001

Podemos também buscar dados de fontes externas, comparar com dados de execuções passadas que estejam armazenados em um banco de dados ou fazer cálculos mais complexos para definir o nosso valor de referência.

O importante é que sempre o retorno do método get_threshold seja um valor que possa ser usado na comparação com a estatística que queremos.

Na documentação é possível encontrar mais exemplo e opções para os nossos monitores, além de um conjunto de monitores pré-definidos para as validações mais comuns nos projetos diminuindo a quantidade de código que precisamos escrever para começar a monitorar nossos projetos.

Próximos passos

Ver o resultado dos nossos monitores apenas nos logs não é muito prático. O que precisamos fazer em seguida é configurar nosso projeto para que alguma ação seja tomada em caso de falha (ou de sucesso).

Para isso, precisamos definir actions. Na extensão temos integrações prontas para receber notificações por e-mail, Slack, Telegram ou Sentry, além de ser possível criar suas próprias ações de acordo com as necessidades do projeto.

Na documentação é possível encontrar mais informações sobre como defini-las e configurá-las.