A autenticação que vem com o Django é boa o suficiente para os casos mais comuns, mas você pode ter necessidades não atendidas pelo padrão out-of-the-box. Personalizar a autenticação em seus projetos requer entender que pontos do sistema fornecido são extensíveis ou substituíveis. Este documento fornece detalhes sobre como o sistema de autenticação pode ser personalizado.
\nAuthentication backends fornece um sistema extensível para quando um nome de usuário e uma senha, armazenados com o modelo de usuário, precisam ser autenticados contra um serviço diferente do padrão do Django.
\nVocê pode dar para seus models permissões customizadas que pode ser conferidas através do sistema de autorização do Django.
\nVocê pode extender o modelo User padrão, ou substituir por um modelo completamente personalizado.
Pode haver várias vezes que você precise enganchar em outro código de autenticação, outro código de usuário ou senha ou métodos de autenticação.
\nPor exemplo, sua companhia pode já ter um LDAP configurado que armazena o usuário e a senha para cada empregado. Isto é um aborrecimento para ambos administradores de rede e os próprios usuários se os usuários tiverem contas separadas em LDAP e a aplicação baseada em Django.
\nEntão, para lidar com situações como está, o sistema de autenticação do Django deixa você conectá-lo em outras fontes de autenticação. Você pode sobrescrever o esquema padrão baseado em banco de dados, ou você pode usar o sistema padrão em conjunto com outros sistemas.
\nVeja a referência do backend de autenticação para informação sobre backends de autenticação incluída com Django.
\nBehind the scenes, Django maintains a list of “authentication backends” that it\nchecks for authentication. When somebody calls\ndjango.contrib.auth.authenticate() – as described in How to log\na user in – Django tries authenticating across\nall of its authentication backends. If the first authentication method fails,\nDjango tries the second one, and so on, until all backends have been attempted.
A lista de backends autenticação usada é especificada na definição AUTHENTICATION_BACKENDS. Isto deve ser uma lista de nomes de caminhos Python que apontam para classes Python que sabem como autenticar. Essas classes podem estar em qualquer lugar no seu caminho Python (python path).
Por padrão, :settings:`AUTHENTICATION_BACKENDS` é definido como:
\n["django.contrib.auth.backends.ModelBackend"]\nThat’s the basic authentication backend that checks the Django users database\nand queries the built-in permissions. It does not provide protection against\nbrute force attacks via any rate limiting mechanism. You may either implement\nyour own rate limiting mechanism in a custom auth backend, or use the\nmechanisms provided by most web servers.
\nA ordem dos :settings:`AUTHENTICATION_BACKENDS` importa, então se o mesmo usuário e senha são válidos em múltiplos backends, Django vai parar de processar na primeira combinação positiva.
\nSe um “backends” emitir uma exceção PermissionDenied, a autenticação irá falhar imediatamente. Django não irá verificar os próximos “backends”.
Um backend de autenticação é uma classe que implementa dois métodos obirgatórios: get_user(user_id) e o authenticate(request, **credentials), assim como um conjunto opcional de métodos de autorização relacionados a permissão.
O método get_user recebe um user_id – o qual pode ser um username, ID do banco de dados ou outr coisa qualquer, mas tem que ser uma chave-primária do seu objeto user – e retorna um objeto user ou None.
The authenticate method takes a request argument and credentials as\nkeyword arguments. Most of the time, it’ll look like this:
from django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\nMas ele poderia também autenticar um token, tal qual:
\nfrom django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nDa mesma maneira, o authenticate() deve verificar as credenciais que recebe e retornar um objeto do tipo “user” que combine com aquelas credenciais se estas forem válidas. Se estas não forem válidas, ele deve retornar None.
O request é uma HttpRequest e pode ser None se não foi fornecido para a authenticate() (a qual o passa para o backend).
The Django admin is tightly coupled to the Django User object. For example, for a user to access the admin,\nUser.is_staff and User.is_active must be True (see\nAdminSite.has_permission() for details).
The best way to deal with this is to create a Django User object for each\nuser that exists for your backend (e.g., in your LDAP directory, your external\nSQL database, etc.). You can either write a script to do this in advance, or\nyour authenticate method can do it the first time a user logs in.
Here’s an example backend that authenticates against a username and password\nvariable defined in your settings.py file and creates a Django User\nobject the first time a user authenticates. In this example, the created Django\nUser object is a superuser who will have full access to the admin:
from django.conf import settings\nfrom django.contrib.auth.backends import BaseBackend\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\n\nclass SettingsBackend(BaseBackend):\n """\n Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.\n\n Use the login name and a hash of the password. For example:\n\n ADMIN_LOGIN = 'admin'\n ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='\n """\n\n def authenticate(self, request, username=None, password=None):\n login_valid = settings.ADMIN_LOGIN == username\n pwd_valid = check_password(password, settings.ADMIN_PASSWORD)\n if login_valid and pwd_valid:\n try:\n user = User.objects.get(username=username)\n except User.DoesNotExist:\n # Create a new user. There's no need to set a password\n # because only the password from settings.py is checked.\n user = User(username=username) # is_active defaults to True.\n user.is_staff = True\n user.is_superuser = True\n user.save()\n return user\n return None\n\n def get_user(self, user_id):\n try:\n return User.objects.get(pk=user_id)\n except User.DoesNotExist:\n return None\nPara criar permissões persaonalizadas para um dado objeto de modelo, use o permissions model Meta attribute.
This example Task model creates two custom permissions, i.e., actions users\ncan or cannot do with Task instances, specific to your application:
class Task(models.Model):\n ...\n\n class Meta:\n permissions = [\n ("change_task_status", "Can change the status of tasks"),\n ("close_task", "Can remove a task by setting its status as closed"),\n ]\nThe only thing this does is create those extra permissions when you run\nmanage.py migrate (the function that creates permissions\nis connected to the post_migrate signal).\nYour code is in charge of checking the value of these permissions when a user\nis trying to access the functionality provided by the application (changing the\nstatus of tasks or closing tasks.) Continuing the above example, the following\nchecks if a user may close tasks:
user.has_perm("app.close_task")\nUsuário existenteLink para este cabeçalho#Existem duas maneiras de estender o modelo padrão User sem substituir seu próprio modelo. Se as mnudanças que precisa são puramente comprtamentais, e nao requerem nenhuma mudança no que é armazenado no banco de dados, você pode criar um proxy model baseado na User. Isso permite qualquer das funcionalidades oferecidas pelo modelo “proxy” incluindo “ordering” padrão, “managers” personalizados ou métodos persononalizados do modelo.
Se você deseja armazenar informação relacionada ao User, você pode usar a OneToOneField para um modelo contento os campos para a informação adicional. Este modelo com relação um-pra-um é muitas vezes chamado modelo de perfil, uma vez que poderia armazenar infomração que nao está relacionada com autenticação sobre o usuário do site. Por exemplo você poderia criar um modelo “Employee”
from django.contrib.auth.models import User\n\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nAssuming an existing Employee Fred Smith who has both a User and Employee\nmodel, you can access the related information using Django’s standard related\nmodel conventions:
\n>>> u = User.objects.get(username="fsmith")\n>>> freds_department = u.employee.department\nPara adicionar os campos do modelo de perfil para uma página de usuário no admin, defina uma InlineModelAdmin (para este exemplo, iremos usar uma StackedInline) no admin.py da sua aplicação e a adicione a classe UserAdmin a qual é registrada com a classe User:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.models import User\n\nfrom my_user_profile_app.models import Employee\n\n\n# Define an inline admin descriptor for Employee model\n# which acts a bit like a singleton\nclass EmployeeInline(admin.StackedInline):\n model = Employee\n can_delete = False\n verbose_name_plural = "employee"\n\n\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = [EmployeeInline]\n\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nOs modelos “profile” não são especiais de maneira alguma - eles são apenas modelos Django que possuem uma relação um-para-um com o modelo “user”. Assim sendo, eles não são criados automaticamente quando um usuário é criado, más um django.db.models.signals.post_save pode ser usado para criar ou atualizar um modelo relacionado se for apropriado.
Usar modelos relacionados resultam em “queries” adicionais ou “joins” para retornar os dados relacionados. Dependendo de suas necessidades, talvez seja uma melhor opção um modelo “user” customizado que inclua os campos relacionados, porém, relações com o modelo “user” já existente dentro das apps do seu projeto talvez justifiquem a carga extra do banco de dados.
\nUsuário personalizadoLink para este cabeçalho#Alguns tipos de projetos talvez tenham requerimentos de autenticação para as quais o modelo User embutido do Django nem sempre é apropriado. Por exemplo, em alguns sites tenha mais sentido usar um endereço de e-mail como seu “token” de identificação no lugar de um nome de usuáro.
O Django permite que você sobrescreva o modelo “user” padrão, fornecendo um valor para o AUTH_USER_MODEL definindo a referência para um modelo personalizado:
AUTH_USER_MODEL = "myapp.MyUser"\nThis dotted pair describes the label of the\nDjango app (which must be in your INSTALLED_APPS), and the name of\nthe Django model that you wish to use as your user model.
If you’re starting a new project, you can set up a custom user model that\nbehaves identically to the default user model by subclassing\nAbstractUser:
from django.contrib.auth.models import AbstractUser\n\n\nclass User(AbstractUser):\n pass\nNão se esqueça de indicá-lo no AUTH_USER_MODEL. Faça isso antes de criar qualquer migração ou antes de rodar um manage.py migrate pela primeira vez.
Além disso, registre o model no app’s ‘’admin.py’’:
\nfrom django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nChanging AUTH_USER_MODEL after you’ve created database tables is\npossible, but can be complex, since it affects foreign keys and many-to-many\nrelationships, for example.
Está modificação não pode ser feita automaticamente e requer um conserto manual do esquema, movendo os dados da antiga tabela de usuários e, possivelmente reaplicando manualmente algumas migrações. Veja #25313 para um esboço das etapas.
\nDevido às limitações do recurso de dependência dinâmica do Django para modelos intercambiáveis, o modelo referenciado por AUTH_USER_MODEL deve ser criado na primeira migração do seu aplicativo (usualmente chamada de 0001_initial); caso contrário, você terá problemas de dependência.
Além disso, você pode ter um `` CircularDependencyError`` ao executar suas migrações, pois o Django não será capaz de quebrar automaticamente o loop de dependência devido à dependência dinâmica. Se você tiver este erro, você deverá quebrar o loop movendo os modelos dependentes, do seu modelo de usuário, para uma segunda migração. (Você pode tentar criando dois modelos normais, onde cada um possui uma ForeignKey para o outro e ver como o makemigrations resolve essa dependência circular.)
AUTH_USER_MODELLink para este cabeçalho#Aplicações reutilizáveis não devem implmentar um modelo de usuário personalizado. Um projeto pode usar muitas aplicações, e duas aplicações reutilizáveis que implementam um modelo de usuário personalizado não poderiam ser usadas juntas. Se você precisa armazenar informação por usuário na sua aplicação, use um ForeignKey ou OneToOneField para o settings.AUTH_USER_MODEL como descrito abaixo.
UsuárioLink para este cabeçalho#Se você referênciar diretamente User (por exemplo, referenciando ele em uma chave estrangeira), seu código não ira funcionar em projetos onde a configuração AUTH_USER_MODEL tenha sido modificada para um modelo de usuário diferente.
Ao invés de fazer uma referencia direta ao User, você deve referenciar o modelo do usuário usando o django.contrib.auth.get_user_model(). Este método irá retornar o modelo de usuário ativo no momento – o modelo de usuário personalizado se este estiver especificado, ou se não, o User.
Quando se define uma chave estrangeira ou relacionamentos muitos-para-muitos com o modelo de usuário, você deve especificar o modelo personalizado usando a definição AUTH_USER_MODEL. Por exemplo:
from django.conf import settings\nfrom django.db import models\n\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\nQuando conectar a sinais enviados pelo modelo de usuário, você deve especificar o modelo personalizado definindo o AUTH_USER_MODEL. Por exemplo:
from django.conf import settings\nfrom django.db.models.signals import post_save\n\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nDe um modo geral, é mais fácil se referir ao modelo do usuário com o AUTH_USER_MODEL definindo no código que é executado no momento da importação, no entanto também é possível chamar get_user_model() enquanto o Django esta importando modelos, para que você possa usar models.ForeignKey(get_user_model(), ...).
If your app is tested with multiple user models, using\n@override_settings(AUTH_USER_MODEL=...) for example, and you cache the\nresult of get_user_model() in a module-level variable, you may need to\nlisten to the setting_changed signal to clear\nthe cache. For example:
from django.apps import apps\nfrom django.contrib.auth import get_user_model\nfrom django.core.signals import setting_changed\nfrom django.dispatch import receiver\n\n\n@receiver(setting_changed)\ndef user_model_swapped(*, setting, **kwargs):\n if setting == "AUTH_USER_MODEL":\n apps.clear_cache()\n from myapp import some_module\n\n some_module.UserModel = get_user_model()\nWhen you start your project with a custom user model, stop to consider if this\nis the right choice for your project.
\nKeeping all user related information in one model removes the need for\nadditional or more complex database queries to retrieve related models. On the\nother hand, it may be more suitable to store app-specific user information in a\nmodel that has a relation with your custom user model. That allows each app to\nspecify its own user data requirements without potentially conflicting or\nbreaking assumptions by other apps. It also means that you would keep your user\nmodel as simple as possible, focused on authentication, and following the\nminimum requirements Django expects custom user models to meet.
\nSe você usa o “backend” padrão de autenticação, então seu modelo deve ter um único campo “unique” que possa ser usado com o propósito de identificação. Isso pode ser um nome de usuário, um endereço de e-mail, ou qualquer atributo “unique”. Um nome de usuário que permita duplicaidade é permitido se você usar um “backend” de autenticação que dê suporte a isso.
\nA maneira mais fácil de construir um modelo de usuário personalizado compatível é herdar de AbstractBaseUser. A AbstractBaseUser fornece o mínimo necessário para implementar um modelo de usuário, incluindo senhas criptografadas e “resets” de senha. Você deve então fornecer alguns detalhes chaves da implementação:
A string describing the name of the field on the user model that is\nused as the unique identifier. This will usually be a username of some\nkind, but it can also be an email address, or any other unique\nidentifier. The field must be unique (e.g. have unique=True set\nin its definition), unless you use a custom authentication backend that\ncan support non-unique usernames.
No exemplo seguinte, o campo identifier é usado como o campo identificador:
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = "identifier"\nA string describing the name of the email field on the User model.\nThis value is returned by\nget_email_field_name().
Um lista de nomes de campos que serão demandados quando criar um usuário através do coando de gerenciamento createsuperuser. O usuário será demandado a fornecer um valor para cada um destes campos. Isso deve incluir qualquer campo para o qual o blank é False ou indefinido e pode incluir campos adicionais que você queira demandar quando o usuário for criado interativamente. O REQUIRED_FIELDS não tem efeito em outras partes do Django, como criar um usuario no admin.
Por exemplo, aqui é a definição parcial para um modelo de usuário que define dois campos obrigatórios - data de nascimento e peso:
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ["date_of_birth", "height"]\nA boolean attribute that indicates whether the user is considered\n“active”. This attribute is provided as an attribute on\nAbstractBaseUser defaulting to True. How you choose to\nimplement it will depend on the details of your chosen auth backends.\nSee the documentation of the is_active attribute on the built-in\nuser model for details.
Optional. A longer formal identifier for the user such as their full\nname. If implemented, this appears alongside the username in an\nobject’s history in django.contrib.admin.
Optional. A short, informal identifier for the user such as their\nfirst name. If implemented, this replaces the username in the greeting\nto the user in the header of django.contrib.admin.
Os atributos e métodos a seguir estão disponíveis em qualquer subclasse de AbstractBaseUser:
Retorna o valor do campo denominado no USERNAME_FIELD.
Normaliza o nome de usuário chamando normalize_username(). Se sobreescrever este método, lembre-se de chamar o super() para manter a normlização.
Returns the name of the email field specified by the\nEMAIL_FIELD attribute. Defaults to\n'email' if EMAIL_FIELD isn’t specified.
Aplica normalização NFKC de UNICODE para nomes de usuários de modo que caracteres visualmente idênticos com pontos diferentes são considerados idênticos.
\nAtributo somente de leitura que está sempre definido como True``(oposto ao `AnonymousUser.is_authenticated que é sempre False). Esta á a maneira de dizer se o usuário foi atenticado. Isso não implica em verificação de nenhuma permissão e não verifica se o usuário é ativo ou tem uma sessão válida. Mesmo que normalmente você irá verificar este atributo no request.user para descobrir se foi populado pelo AuthenticationMiddleware (representando o usuário logado atualmente), você deve saber se este atributo é True para qualquer instância de User.
Atributo somente de leitura o qual é sempre definido como False. Esta é a maneira de diferenciar objetos do tipo User e AnonymousUser. Geralmente, você deve preferir usar o is_authenticated a este atributo.
Define a senha do usuário para uma dada string simples, levando em conta a criptografia da senha. Não salva o objeto AbstractBaseUser.
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
Asynchronous version: acheck_password()
Retorna ``True``se a string simples é a senha correta para o usuário. (leva em conta a criptografia da senha quando fizer a comparação.)
\nMarks the user as having no password set. This isn’t the same as\nhaving a blank string for a password.\ncheck_password() for\nthis user will never return True. Doesn’t save the\nAbstractBaseUser object.
Você talvez precise disso se a autenticação para sua aplicação é feita em uma fonte externa existente como um diretório LDAP.
\nReturns False if\nset_unusable_password()\nhas been called for this user.
Retorna um HMAC do campo senha. Usado para “Invalidação de Sessão após a Troca de Senha.” isto é, invalidar sessão no caso de alteração de password.
\nYields the HMAC of the password field using\nSECRET_KEY_FALLBACKS. Used by get_user().
AbstractUser subclasses AbstractBaseUser:
Normalizes the email by calling\nBaseUserManager.normalize_email(). If you override this method,\nbe sure to call super() to retain the normalization.
You should also define a custom manager for your user model. If your user model\ndefines username, email, is_staff, is_active, is_superuser,\nlast_login, and date_joined fields the same as Django’s default user,\nyou can install Django’s UserManager;\nhowever, if your user model defines different fields, you’ll need to define a\ncustom manager that extends\nBaseUserManager providing two additional\nmethods:
O protótipo de create_user()``deve aceitar o campo "username" , mais todos os campos requeridos como argumentos. Por exemlo, se seu modelo de usuário usa ``email como o campo username, e tem date_of_birth como campo requerido, então create_user deve ser definido como:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nO protótipo de create_superuser()``deve aceitar o campo "username" , mais todos os campos requeridos como argumentos. Por exemlo, se seu modelo de usuário usa ``email como o campo “username”, e tem date_of_birth como campo requerido, então create_user deve ser definido como:
def create_superuser(self, email, date_of_birth, password=None):\n # create superuser here\n ...\nFor a ForeignKey in USERNAME_FIELD or\nREQUIRED_FIELDS, these methods receive the value of the\nto_field (the primary_key\nby default) of an existing instance.
BaseUserManager fornece os seguintes métodos de utilidade:
Normaliza o endereço de email colocando em minúsculas a porção do domínio do endereço de email.
\nAsynchronous version: aget_by_natural_key()
Retornar uma instância de usuário usando o conteúdo do campo denominado no USERNAME_FIELD.
Usuário padrão do DjangoLink para este cabeçalho#If you’re entirely happy with Django’s\nUser model, but you want to add some\nadditional profile information, you could subclass\ndjango.contrib.auth.models.AbstractUser and add your custom profile\nfields, although we’d recommend a separate model as described in\nDefinindo um modelo de usuário personalizado.. AbstractUser provides the full\nimplementation of the default User as an\nabstract model.
Os forms e views embutidos no Django tem certas premissas sobre o modelo de usuário que eles estão trabalhando.
\nOs “forms” seguintes são compatíveis com qualquer subclasse de AbstractBaseUser:
A AuthenticationForm: usa o campo username especificado pelo USERNAME_FIELD.
Os seguintes forms fazem suposições quanto ao modelo de usuário e podem ser usadas tal como estão se estas suposições forem válidas:
\nPasswordResetForm: Assumes that the user\nmodel has a field that stores the user’s email address with the name returned\nby get_email_field_name() (email by\ndefault) that can be used to identify the user and a boolean field named\nis_active to prevent password resets for inactive users.
Finalmente, os seguintes forms estão amarrados a User e precisa ser rescrito ou estendido para funcionar com o modelo de usuário personalizado:
If your custom user model is a subclass of AbstractUser, then you can\nextend these forms in this manner:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\n\nclass CustomUserCreationForm(UserCreationForm):\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ("custom_field",)\ndjango.contrib.adminLink para este cabeçalho#Se você quer que seu modelo de usuário personalizado também funcione com o “admin”, seu modelo de usuário deve definir alguns atributos e métodos adicionais. Estes métodos permitem que o “admin” controle o acesso do usuário ao conteúdo do “admin”.
\nRetorna ``True``se o usuário está permitido a ter acesso ao site admin.
\nRetorna True se a conta de usuário estiver ativa.
Retorna True``se o usuário tem a permissão nominada. Se ``obj é fornecido, a permissão necessária para ser verificado para uma instância de objeto específica.
Retorna ``True``se o usuário tem permissão para acessar modelos na dada aplicação.
\nVocê também irá precisar registrar seu modelo de usuário personalizado com o “admin”. Se seu modelo ersonalizado herda de django.contrib.auth.models.AbstractUser, você pode usar a classe já existente django.contrib.auth.admin.UserAdmin. Porém, se seu modelo de usuário herda de AbstractBaseUser, você precisa definir uma classe personalizada de ModelAdmin. Pode ser que seja possível herdar da django.contrib.auth.admin.UserAdmin padrão; porém, será necessário sobrescrever qualquer das definições que se referem a campos do ``django.contrib.auth.models.AbstractUser``e que não estejam no sua classe de usuário personalizado.
Para tornar fácil a inclusão do mecanismo de permissão do Django na sua classe de usuário, o Django fornece a PermissionsMixin. Ela é uma classe de modelo abstrato que você pode incluir na hierarquia de classes do seu modelo, lhe dando todos os métodos e campos do banco de dados necessários de modo a funcionar como modelo de permissão do Django.
PermissionsMixin fornece os seguintes métodos e atributos:
Booleano. Designa que este user tem todas as permissões sem assinalá-las explicitamente.
\nReturns a set of permission strings that the user has directly.
\nIf obj is passed in, only returns the user permissions for this\nspecific object.
Retorna um conjunto de strings de permissões que o usuário tem através de seus grupos.
\nSe o obj é passado, somente retorna o grupo de permissões para este objeto específico.
Retorna um conjunto de strings de permissões que o usuário tem, através de ambos permissões de grupo e usuário.
\nSe o obj é passado, somente retorna as permissões para este objeto específico.
Returns True if the user has the specified permission, where\nperm is in the format "<app label>.<permission codename>" (see\npermissions). If User.is_active\nand is_superuser are both True, this method always\nreturns True.
Se obj é passado, este método não irá verificar por permissões para o modelo, mas para este objeto específico.
Returns True if the user has each of the specified permissions,\nwhere each perm is in the format\n"<app label>.<permission codename>". If User.is_active and\nis_superuser are both True, this method always\nreturns True.
Se obj é passado, este método não irá verificar por permissões para o modelo, mas para este objeto específico.
Returns True if the user has any permissions in the given package\n(the Django app label). If User.is_active and\nis_superuser are both True, this method always\nreturns True.
Uma das limitações de modelos de usuário personalizados é que ao instalar uma classe de modelo de usuário personalizado qualquer modelo “proxy” que estenda a User irá quebrar. Modelos do tipo “proxy” devem ser baseados em uma classe base concreta; ao definir um modelo de usuário personalizado, você está removendo a habilidade do Django de identificar a classe base de maneira confiável.
Se seu projeto usa modelos “proxy”, você deve modificar o “proxy” para herdar do modelo de usuário em uso no seu projeto, ou juntar o comportamento do seu “proxy” dentro da sua subclasse de User.
Here is an example of an admin-compliant custom user app. This user model uses\nan email address as the username, and has a required date of birth; it\nprovides no permission checking beyond an admin flag on the user account.\nThis model would be compatible with all the built-in auth forms and views,\nexcept for the user creation forms. This example illustrates how most of the\ncomponents work together, but is not intended to be copied directly into\nprojects for production use.
Todo este código deve estar no arquivo “models.py” para um aplicativo de autenticação customizável:
\nfrom django.db import models\nfrom django.contrib.auth.models import BaseUserManager, AbstractBaseUser\n\n\nclass MyUserManager(BaseUserManager):\n def create_user(self, email, date_of_birth, password=None):\n """\n Creates and saves a User with the given email, date of\n birth and password.\n """\n if not email:\n raise ValueError("Users must have an email address")\n\n user = self.model(\n email=self.normalize_email(email),\n date_of_birth=date_of_birth,\n )\n\n user.set_password(password)\n user.save(using=self._db)\n return user\n\n def create_superuser(self, email, date_of_birth, password=None):\n """\n Creates and saves a superuser with the given email, date of\n birth and password.\n """\n user = self.create_user(\n email,\n password=password,\n date_of_birth=date_of_birth,\n )\n user.is_admin = True\n user.save(using=self._db)\n return user\n\n\nclass MyUser(AbstractBaseUser):\n email = models.EmailField(\n verbose_name="email address",\n max_length=255,\n unique=True,\n )\n date_of_birth = models.DateField()\n is_active = models.BooleanField(default=True)\n is_admin = models.BooleanField(default=False)\n\n objects = MyUserManager()\n\n USERNAME_FIELD = "email"\n REQUIRED_FIELDS = ["date_of_birth"]\n\n def __str__(self):\n return self.email\n\n def has_perm(self, perm, obj=None):\n "Does the user have a specific permission?"\n # Simplest possible answer: Yes, always\n return True\n\n def has_module_perms(self, app_label):\n "Does the user have permissions to view the app `app_label`?"\n # Simplest possible answer: Yes, always\n return True\n\n @property\n def is_staff(self):\n "Is the user a member of staff?"\n # Simplest possible answer: All admins are staff\n return self.is_admin\nThen, to register this custom user model with Django’s admin, the following\ncode would be required in the app’s admin.py file:
from django import forms\nfrom django.contrib import admin\nfrom django.contrib.auth.models import Group\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.forms import ReadOnlyPasswordHashField\nfrom django.core.exceptions import ValidationError\n\nfrom customauth.models import MyUser\n\n\nclass UserCreationForm(forms.ModelForm):\n """A form for creating new users. Includes all the required\n fields, plus a repeated password."""\n\n password1 = forms.CharField(label="Password", widget=forms.PasswordInput)\n password2 = forms.CharField(\n label="Password confirmation", widget=forms.PasswordInput\n )\n\n class Meta:\n model = MyUser\n fields = ["email", "date_of_birth"]\n\n def clean_password2(self):\n # Check that the two password entries match\n password1 = self.cleaned_data.get("password1")\n password2 = self.cleaned_data.get("password2")\n if password1 and password2 and password1 != password2:\n raise ValidationError("Passwords don't match")\n return password2\n\n def save(self, commit=True):\n # Save the provided password in hashed format\n user = super().save(commit=False)\n user.set_password(self.cleaned_data["password1"])\n if commit:\n user.save()\n return user\n\n\nclass UserChangeForm(forms.ModelForm):\n """A form for updating users. Includes all the fields on\n the user, but replaces the password field with admin's\n disabled password hash display field.\n """\n\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]\n\n\nclass UserAdmin(BaseUserAdmin):\n # The forms to add and change user instances\n form = UserChangeForm\n add_form = UserCreationForm\n\n # The fields to be used in displaying the User model.\n # These override the definitions on the base UserAdmin\n # that reference specific fields on auth.User.\n list_display = ["email", "date_of_birth", "is_admin"]\n list_filter = ["is_admin"]\n fieldsets = [\n (None, {"fields": ["email", "password"]}),\n ("Personal info", {"fields": ["date_of_birth"]}),\n ("Permissions", {"fields": ["is_admin"]}),\n ]\n # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin\n # overrides get_fieldsets to use this attribute when creating a user.\n add_fieldsets = [\n (\n None,\n {\n "classes": ["wide"],\n "fields": ["email", "date_of_birth", "password1", "password2"],\n },\n ),\n ]\n search_fields = ["email"]\n ordering = ["email"]\n filter_horizontal = []\n\n\n# Now register the new UserAdmin...\nadmin.site.register(MyUser, UserAdmin)\n# ... and, since we're not using Django's built-in permissions,\n# unregister the Group model from admin.\nadmin.site.unregister(Group)\nFinalmente, especifique o model customizado como sendo o “user model” padrão para o seu projeto, utilizando para isso, AUTH_USER_MODEL no arquivo “settings.py”:
AUTH_USER_MODEL = "customauth.MyUser"\nTo optimize performance when called from an async context authentication,\nbackends can implement async versions of each function - aget_user(user_id)\nand aauthenticate(request, **credentials). When an authentication backend\nextends BaseBackend and async versions of these functions are not provided,\nthey will be automatically synthesized with sync_to_async. This has\nperformance penalties.
While an async interface is optional, a synchronous interface is always\nrequired. There is no automatic synthesis for a synchronous interface if an\nasync interface is implemented.
\nDjango’s out-of-the-box authentication backends have native async support. If\nthese native backends are extended take special care to make sure the async\nversions of modified functions are modified as well.
\n