---
title: "Usando o sistema de autenticação Django"
version: 4.0
locale: pt-br
source: https://docs.djangoproject.com/pt-br/4.0/topics/auth/default/
canonical: https://djangodocs.dev/pt-br/4.0/topics/auth/default/
---
# Usando o sistema de autenticação Django

Este documento explica a utilização do sistema de autenticações do Django em suas configurações padrões. Estas configurações evoluíram para atender as necessidades mais comuns de um projeto, lidando com uma considerável quantidade de tarefas e implementando cuidadosamente, o uso de senhas e permissões. Para projetos onde o sistema de autenticações demande outras necessidades diferentes das padrões, o Django oferece suporte para uma extensiva customização:  [extension and customization](/pt-br/4.0/topics/auth/customizing/) de autenticação.

A autenticação do Django oferece, tanto autenticação como autorização juntos. Estes serviços são referenciados como “sistema de autenticação” uma vez estas funções são, de alguma forma, interligadas.

## Objetos “User”

Os objetos do tipo [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) são o núcleo do sistema de autenticação. Eles tipicamente representam as pessoas interagindo com seu site e são usados para habilitar coisas como restrinção de acesso, registro de perfis de usuários, associar conteúdo com criadores etc. Somente uma classe de usuário existe no “framework” de autenticação do Django, isto é, usuários [`'superusers'`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.is_superuser) ou admin [`'staff'`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.is_staff) são somente objetos do tipo “user” com atributos especiais definidos e não classes diferentes de objetos “user”.

Os atributos primários de usuário padrão são:

- [`username`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.username)
- [`password`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.password)
- [`email`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.email)
- [`first_name`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.first_name)
- [`last_name`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.last_name)

Veja a :class:\` documentação completa da API \<django.contrib.auth.models.User\>\` para maiores detalhes, a documentação em questão é mais orientada a tarefa.

### Criando usuários

A forma mais direta para se criar usuários, é utilizando a função de ajuda inclusa [`create_user()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.UserManager.create_user) helper function:

```
>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()
```

Se você tiver a administração do Django instalado, você também pode: ref: \` criar usuários de forma interativa \< auth -admin \>\` .

### Criando superusuários

Criando superusuários usando o commando [`createsuperuser`](/pt-br/4.0/ref/django-admin/#django-admin-createsuperuser)

```
$ python manage.py createsuperuser --username=joe --email=joe@example.com
```

Será solicitada então uma senha. Após inserí-la, a conta de usuário será criada imediatamente. Caso seja desligada a opção:[`--username`](/pt-br/4.0/ref/django-admin/#cmdoption-createsuperuser-username) ou [`--email`](/pt-br/4.0/ref/django-admin/#cmdoption-createsuperuser-email), estes valores serão solicitados.

### Mudando as senhas

O Django não armazena senha em sua forma bruta (texto limpo) no modelo do usuário, mas somente um “hash” (see [documentação de como as senhas são manipuladas](/pt-br/4.0/topics/auth/passwords/) para detalhes completos). Por causa disso, não tente manipular diretamente o atributo “password” do usuário. Este é o porque de uma função auxiliar ser usada para criar um usuário.

Para mudar a senha de usuários, você tem várias opções:

[`manage.py changepassword *username*`](/pt-br/4.0/ref/django-admin/#django-admin-changepassword) offers a method
of changing a user’s password from the command line. It prompts you to
change the password of a given user which you must enter twice. If
they both match, the new password will be changed immediately. If you
do not supply a user, the command will attempt to change the password
whose username matches the current system user.

Você pode também mudar a senha programaticamente, usando [`set_password()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.set_password):

```pycon
>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()
```

Se você tiver a administração do Django instalado, você também pode alterar a senha do usuário nas : ref: páginas de administração do \` sistema de autenticação \< auth -admin \>\` .

Django também fornece : ref: \` views \< built-in -auth- vistas \>\` e : ref: \` forms \< built-in -auth-forms\>\` que podem ser utilizados para permitir que os usuários alterem suas próprias senhas.

Mudar a senha de um usuário irá “deslogar” todas as suas sessões. Para detalhes veja  ref:session-invalidation-on-password-change.

### Autenticando usuários

#### `authenticate(request=None, **credentials)`

Use a [`authenticate()`](#django.contrib.auth.authenticate) para verificar um conjunto de credenciais. Ela recebe as credenciais como argumentos nomeados, `username` e `password` para o caso padrão, e os checa com todos os [backends de autenticação](/pt-br/4.0/topics/auth/customizing/#authentication-backends), e retornar um objeto [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) se as credenciais forem válidas para um dos backends. Se as credenciais não forem válidas para qualquer um dos “backends” ou se um “backend” emitir uma [`PermissionDenied`](/pt-br/4.0/ref/exceptions/#django.core.exceptions.PermissionDenied), ele retorna `None`. Por exemplo:

```
from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    # A backend authenticated the credentials
else:
    # No backend authenticated the credentials
```

`request` is an optional [`HttpRequest`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest) which is
passed on the `authenticate()` method of the authentication backends.

> **Note**
>
> This is a low level way to authenticate a set of credentials; for
> example, it’s used by the
> [`RemoteUserMiddleware`](/pt-br/4.0/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware). Unless
> you are writing your own authentication system, you probably won’t use
> this. Rather if you’re looking for a way to login a user, use the
> [`LoginView`](#django.contrib.auth.views.LoginView).

## Permissões e Autorização

Django comes with a built-in permissions system. It provides a way to assign
permissions to specific users and groups of users.

É usado pelo site admin Django, mas você é livre para usar em seu próprio código.

O site admin Django usa as seguintes permissões:

- Access to view objects is limited to users with the “view” or “change”
  permission for that type of object.
- Acesso para visualizar o formulário “adicionar” e adicionar um objeto é limitado para usuários com a permissão “adicionar” para aquele tipo de objeto.
- Acesso para visualizar o formulário “editar” e editar um objeto é limitado para usuários com a permissão “editar” para aquele tipo de objeto.
- Acesso para remover um objeto é limitado para usuários com a permissão “remover” para aquele tipo de objeto.

Permissions can be set not only per type of object, but also per specific
object instance. By using the
[`has_view_permission()`](/pt-br/4.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_view_permission),
[`has_add_permission()`](/pt-br/4.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_add_permission),
[`has_change_permission()`](/pt-br/4.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_change_permission) and
[`has_delete_permission()`](/pt-br/4.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_delete_permission) methods provided
by the [`ModelAdmin`](/pt-br/4.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin) class, it is possible to
customize permissions for different object instances of the same type.

Os objetos da [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) tem dois campos muitos-para-muitos: `groups` e `user_permissions`. Os objetos do tipo [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) podem acessar seus objetos relacionados da mesma maneira que qualquer outro [Django model](/pt-br/4.0/topics/db/models/):

```
myuser.groups.set([group_list])
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions.set([permission_list])
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()
```

### Permissões padrão

When `django.contrib.auth` is listed in your [`INSTALLED_APPS`](/pt-br/4.0/ref/settings/#std-setting-INSTALLED_APPS)
setting, it will ensure that four default permissions – add, change, delete,
and view – are created for each Django model defined in one of your installed
applications.

Estas permissões serão criadas quando você rodar [`manage.py migrate`](/pt-br/4.0/ref/django-admin/#django-admin-migrate); A primeira vez que você executa o `migrate` depois de adicionar o `django.contrib.auth` ao  [`INSTALLED_APPS`](/pt-br/4.0/ref/settings/#std-setting-INSTALLED_APPS), as permissões padrão serão criadas para todos os modelos pré-instalados, assim como para qualquer novo modelo sendo instalado naquele momento. Ele irá criar permissões padrão para cada novo modelo cada vez que você rodar [`manage.py migrate`](/pt-br/4.0/ref/django-admin/#django-admin-migrate) (a função que cria as permissões está conectada ao sinal [`post_migrate`](/pt-br/4.0/ref/signals/#django.db.models.signals.post_migrate)).

Assumindo que você tenha uma aplicação com um [`app_label`](/pt-br/4.0/ref/models/options/#django.db.models.Options.app_label) `foo` e um modelo chamado `Bar`, para testar as permissões básicas você deve usar:

- Adicionar: `user.has_perm('foo.add_bar')`
- mudar: `user.has_perm('foo.change_bar')`
- deletar: `user.has_perm('foo.delete_bar')`
- view: `user.has_perm('foo.view_bar')`

A [`Permission`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.Permission) é raramente acessada diretamente.

### Grupos

Os modelos [`django.contrib.auth.models.Group`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.Group) são uma maneira genérica de categorizar usuários então você pode aplicar permissões, ou alguma outra etiqueta, àqueles usuários. Um usuário pode pertencer a qualquer número de grupos.

Um usuário em um grupo tem automaticamente todas as permissões concedidas àquele grup. Por exemplo, se o grupo `Site editors` tem uma permissão `can_edit_home_page`,qualquer usuário naquele grupo terá a permissão.

Além de permissões, grupos são uma maneira conveniente de categorizar usuários para dar a eles uma etiqueta, ou uma funcionalidade estendida. Por exemplo, você pode criar um grupo `Special users`, e você pode escrever código que poderia, por exemplo, dar a eles acesso a uma parte do seu site somente para membros daquele grupo, ou enviar a eles mensagens de email.

### Programaticamente criando permissões

Enquanto que as [custom permissions](/pt-br/4.0/topics/auth/customizing/#custom-permissions) podem ser definidas dentro da classe `Meta` de um modelo, você pode criar permissões diretamente. Por exemplo, você pode criar a permissão `can_publish` para um modelo `BlogPost` em `myapp`:

```
from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
    codename='can_publish',
    name='Can Publish Posts',
    content_type=content_type,
)
```

A permissão pode então ser assinalada ao [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) através do seu atributo `user_permissions` ou para um [`Group`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.Group) através de seu atributo `permissions`.

> **Proxy models need their own content type**
>
> If you want to create [permissions for a proxy model](#proxy-models-permissions-topic), pass `for_concrete_model=False` to
> [`ContentTypeManager.get_for_model()`](/pt-br/4.0/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentTypeManager.get_for_model) to get the appropriate
> `ContentType`:
>
> ```
> content_type = ContentType.objects.get_for_model(BlogPostProxy, for_concrete_model=False)
> ```

### Cache de permissões

The [`ModelBackend`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend) caches permissions on
the user object after the first time they need to be fetched for a permissions
check. This is typically fine for the request-response cycle since permissions
aren’t typically checked immediately after they are added (in the admin, for
example). If you are adding permissions and checking them immediately
afterward, in a test or view for example, the easiest solution is to re-fetch
the user from the database. For example:

```
from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404

from myapp.models import BlogPost

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_blogpost')

    content_type = ContentType.objects.get_for_model(BlogPost)
    permission = Permission.objects.get(
        codename='change_blogpost',
        content_type=content_type,
    )
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_blogpost')  # False

    # Request new instance of User
    # Be aware that user.refresh_from_db() won't clear the cache.
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_blogpost')  # True

    ...
```

### Modelos Proxy

Proxy models work exactly the same way as concrete models. Permissions are
created using the own content type of the proxy model. Proxy models don’t
inherit the permissions of the concrete model they subclass:

```
class Person(models.Model):
    class Meta:
        permissions = [('can_eat_pizzas', 'Can eat pizzas')]

class Student(Person):
    class Meta:
        proxy = True
        permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]

>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
...     user.user_permissions.add(permission)
>>> user.has_perm('app.add_person')
False
>>> user.has_perm('app.can_eat_pizzas')
False
>>> user.has_perms(('app.add_student', 'app.can_deliver_pizzas'))
True
```

## Authentication in web requests

O Django usa [sessions](/pt-br/4.0/topics/http/sessions/) e o middleware para vincular o sistema de autenticação dentro dos [`objetos de requisição`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest).

Isso fornece um atributo [`request.user`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.user) para cada requisição que representa o usuário atual. Se o usuário não está “logado”, este atributo será definido como uma instância de [`AnonymousUser`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser), do contrário ele será uma instância de [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User).

Você pode distinguí-los com [`is_authenticated`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.is_authenticated), como a seguir:

```
if request.user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...
```

### Como autenticar um usuário

Caso queira adicionar um usuário autenticado à sessão atual - isto pode ser feito com a função [`login()`](#django.contrib.auth.login).

#### `login(request, user, backend=None)`

Para “logar” um usuário, em uma “view”, use [`login()`](#django.contrib.auth.login). Essa função recebe um objeto [`HttpRequest`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest) e um objeto [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User). A [`login()`](#django.contrib.auth.login) salva o ID do usuário na sessão, usando o framework de sessão do Django.

Note que qualquer dado definido durante um sessão anônima, fica retido na sessão após um usuário logar.

Estes exemplos mostram como é possível utilizar ambas as funções [`authenticate()`](#django.contrib.auth.authenticate) e [`login()`](#django.contrib.auth.login):

```
from django.contrib.auth import authenticate, login

def my_view(request):
    username = request.POST['username']
    password = request.POST['password']
    user = authenticate(request, username=username, password=password)
    if user is not None:
        login(request, user)
        # Redirect to a success page.
        ...
    else:
        # Return an 'invalid login' error message.
        ...
```

#### Selecionando o “backend” de autenticação

Quando um usuário se “loga” no sistema, o ID do usuário e o “backend” que foi usado para autenticação são salvos na sessão. Isso permite que o mesmo [“backend” de autenticação](/pt-br/4.0/topics/auth/customizing/#authentication-backends) seja usado para retornar detalhes do usuário em uma requisição futura. O “backend” de autenticação a ser salvo na sessão é selecionado da seguinte maneira:

1. Usa o valor do argumento `backend` opcional, se fornecido.
2. Use the value of the `user.backend` attribute, if present. This allows
   pairing [`authenticate()`](#django.contrib.auth.authenticate) and
   [`login()`](#django.contrib.auth.login):
   [`authenticate()`](#django.contrib.auth.authenticate)
   sets the `user.backend` attribute on the user object it returns.
3. Use o `backend` no [`AUTHENTICATION_BACKENDS`](/pt-br/4.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), se houver somente um.
4. Caso contrário, gera uma exceção.

Nos casos 1 e 2, o valor do argumento `backend` ou do  atributo `user.backend` deve ser uma string com o caminho de importação na notação de pontos (como aquela encontrada em [`AUTHENTICATION_BACKENDS`](/pt-br/4.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS)), e não a classe de “backend” atual.

### Como finalizar a sessão de um usuário

#### `logout(request)`

Para finalizar a sessão de um usuário que tenha se autenticado via [`django.contrib.auth.login()`](#django.contrib.auth.login), use  [`django.contrib.auth.logout()`](#django.contrib.auth.logout) dentro de sua view. Ele recebe um objeto [`HttpRequest`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest) e não tem um valor de retorno. Exemplo:

```
from django.contrib.auth import logout

def logout_view(request):
    logout(request)
    # Redirect to a success page.
```

Repare que a [`logout()`](#django.contrib.auth.logout) não emiti nenhum erro se o usuário não estiver autenticado.

When you call [`logout()`](#django.contrib.auth.logout), the session data for
the current request is completely cleaned out. All existing data is
removed. This is to prevent another person from using the same web browser
to log in and have access to the previous user’s session data. If you want
to put anything into the session that will be available to the user
immediately after logging out, do that *after* calling
[`django.contrib.auth.logout()`](#django.contrib.auth.logout).

### Limitando o acesso de usuários authenticados

#### A maneira padrão

The raw way to limit access to pages is to check
[`request.user.is_authenticated`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.is_authenticated) and either redirect to a
login page:

```
from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...
```

…  ou mostrar uma mensagem de erro:

```
from django.shortcuts import render

def my_view(request):
    if not request.user.is_authenticated:
        return render(request, 'myapp/login_error.html')
    # ...
```

#### O `login_required` decorator

#### `login_required(redirect_field_name='next', login_url=None)`

Como atalho, você pode usar o decorador conveniente [`login_required()`](#django.contrib.auth.decorators.login_required)

```
from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...
```

A [`login_required()`](#django.contrib.auth.decorators.login_required) faz o seguinte:

- Se o usuário não registrou seu acesso, redireciona para [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL), passando caminho absoluto corrente na “querystring”. Example: `/accounts/login/?next=/polls/3/`.
- Se o usuário está autenticado, executa a “view” normalmente. O código da “view” é livre para assumir que o usuário está autenticado.

Por padrão, o caminho para o qual o usuário deve ser redirecionado após a autenticação está armazenado em um parâmetro na “query string” chamado `"next"`. Se preferir usar um outro nome para este parâmetro, a [`login_required()`](#django.contrib.auth.decorators.login_required) recebe um parâmetro adicional `redirect_field_name`:

```
from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...
```

Repare que se você fornecer um valor para `redirect_field_name`, você deverá também personalizar seus templates de login, já que a variável de contexto do template a qual armazena o caminho de redirecionamento irá usar o valor de  `redirect_field_name` como sua chave ao invés de `"next"` (o padrão).

A [`login_required()`](#django.contrib.auth.decorators.login_required) também receve um parâmetro adicional chamado `login_url`. Example:

```
from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...
```

Repare que se você não especificar o parâmetro `login_url`, terá que ter certeza que o [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL) e sua “view” de login estão associados corretamente. Por exemplo, usando os padrões, adicione a seguinte linha ao seu URLconf:

```
from django.contrib.auth import views as auth_views

path('accounts/login/', auth_views.LoginView.as_view()),
```

A [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL) também aceita nome de funções “view”e [named URL patterns](/pt-br/4.0/topics/http/urls/#naming-url-patterns). Isso permite a você mapear livremente sua “view” de login dentro do URconf sem ter que atualizar o arquivo de definições.

> **Note**
>
> O decorador `login_required` não verifica o indicado `is_active` no usuário, mas a definição padrão de [`AUTHENTICATION_BACKENDS`](/pt-br/4.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) rejeita usuários inativos.

> **See also**
>
> Se estiver escrevendo “views” personalizadas para o admin do Django ( ou precisa da mesma verificação de autorização que as “views” embutidas usam), talvez ache a função decoradora [`django.contrib.admin.views.decorators.staff_member_required()`](/pt-br/4.0/ref/contrib/admin/#django.contrib.admin.views.decorators.staff_member_required) uma alternativa útil para o `login_required()`.

#### O `LoginRequired` mixin

Quando usar [class-based views](/pt-br/4.0/topics/class-based-views/), você pode ter o mesmo comportamento que o `login_required` usando o `LoginRequiredMixin`. Este “mixin” deve estar na última posição mais a esquerda na lista de herança.

#### `class LoginRequiredMixin`

Se a “view” estiver usando o “mixin”, todos as requisições de usuário não autenticados serão redirecionadas para a página de login ou mostram um erro de falta de permissão HTTP 403, dependendo da definição do parâmetro [`raise_exception`](#django.contrib.auth.mixins.AccessMixin.raise_exception).

Você pode definir qualquer dos parâmetros da [`AccessMixin`](#django.contrib.auth.mixins.AccessMixin) para personalizar a maneira como o sistema lida com usuários não autorizados:

```
from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'
```

> **Note**
>
> Tal como o decorador `login_required`, este “mixin” não verifica o indicador `is_active` do usuário, mas o padrão dos [`AUTHENTICATION_BACKENDS`](/pt-br/4.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) é rejeitar usuário inativos.

#### Limitando o acesso de usuários autenticados que passam no teste.

Para limitar o acesso baseado em certas permissões ou outros testes, você deve fazer o mesmo que foi descrito na seção anterior.

You can run your test on [`request.user`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.user) in
the view directly. For example, this view checks to make sure the user has an
email in the desired domain and if not, redirects to the login page:

```
from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...
```

#### `user_passes_test(test_func, login_url=None, redirect_field_name='next')`

Como atalho, você pode usar o conveniente decorador `user_passes_test` o qual executa um redirecionamento quando a função passada retorna `False`:

```
from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...
```

A [`user_passes_test()`](#django.contrib.auth.decorators.user_passes_test) recebe um argumento obrigatório: um executável que recebe um objeto do tipo [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) e retorna `True` se é permitido ao usuário acessar a página. Note que a [`user_passes_test()`](#django.contrib.auth.decorators.user_passes_test) não verifica automaticamente se o [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) não é anônimo.

A [`user_passes_test()`](#django.contrib.auth.decorators.user_passes_test) pode receber dois argumentos opcionais:

**`login_url`**

  Permite que você especifique a URL para a qual os usuários que não passam no teste sejam redirecionados. Pode ser uma página de autenticação e seu padrão é o que estiver definido em [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL) se você não especificar nenhum.

**`redirect_field_name`**

  O mesmo que [`login_required()`](#django.contrib.auth.decorators.login_required). Se definido como `None` ele será removido da URL, o que você talvez queira que aconteça se você estiver redirecionando usuários que não passem no teste para uma página que não é a de autenticação e que não tenha o “next page”.

Por exemplo:

```
@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...
```

#### `class UserPassesTestMixin`

Quando usar as [“views” baseadas em classes](/pt-br/4.0/topics/class-based-views/), você pode usar o `UserPassesTestMixin` para isso.

#### `test_func()`

Você tem que sobrescrever o método `test_func()` da classe para fornecer o teste a ser executado. Mais ainda, você pode definir qualquer dos parâmetros da [`AccessMixin`](#django.contrib.auth.mixins.AccessMixin) para personalizar a manipulação de usuários não autorizados:

```
from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')
```

#### `get_test_func()`

Você pode também sobrescrever o método `get_test_func()` para que seja possível para o “mixin” usar um nome de função diferente para suas verificações (ao invés de [`test_func()`](#django.contrib.auth.mixins.UserPassesTestMixin.test_func)).

> **Empilhando UserPassesTestMixin**
>
> Devido a maneira que o `UserPassesTestMixin` foi implementado, você não pode empilhá-las na sua lista de heranças. O que está descrito a seguir não funciona:
>
> ```
> class TestMixin1(UserPassesTestMixin):
>     def test_func(self):
>         return self.request.user.email.endswith('@example.com')
>
> class TestMixin2(UserPassesTestMixin):
>     def test_func(self):
>         return self.request.user.username.startswith('django')
>
> class MyView(TestMixin1, TestMixin2, View):
>     ...
> ```
>
> Se o `TestMixin1` deve chamar o `super()` e leva o resultado em conta, o `TestMixin1` não irá mais funcionar de maneira independente.

#### O `permission_required` decorator

#### `permission_required(perm, login_url=None, raise_exception=False)`

Verificar se um usuário tem uma permissão é uma tarefa relativamente comum. Por essa razão, o Django fornece um atalho para este caso: o decorador [`permission_required()`](#django.contrib.auth.decorators.permission_required).:

```
from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice')
def my_view(request):
    ...
```

Just like the [`has_perm()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perm) method,
permission names take the form `"<app label>.<permission codename>"`
(i.e. `polls.add_choice` for a permission on a model in the `polls`
application).

O decorador pode também receber um iterável de permissões, e neste caso o usuário deve ter todas as permissões para acessar a “view”.

Note que a [`permission_required()`](#django.contrib.auth.decorators.permission_required) também recebe um parâmetro `login_url` opcional:

```
from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice', login_url='/loginpage/')
def my_view(request):
    ...
```

Assim como no decorador [`login_required()`](#django.contrib.auth.decorators.login_required), o padrão para `login_url` é a definição de [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL).

Se o parâmetro `raise_exception` é fornecido, o decorador irá emitir um [`PermissionDenied`](/pt-br/4.0/ref/exceptions/#django.core.exceptions.PermissionDenied), mostrando o [the 403 (HTTP Forbidden) view](/pt-br/4.0/ref/views/#http-forbidden-view) ao invés de redirecionar para uma página de autenticação.

Se quiser usar o  `raise_exception` mas também dar aos usuários a chance de se autenticar, você pode adicionar o decorador [`login_required()`](#django.contrib.auth.decorators.login_required):

```
from django.contrib.auth.decorators import login_required, permission_required

@login_required
@permission_required('polls.add_choice', raise_exception=True)
def my_view(request):
    ...
```

This also avoids a redirect loop when [`LoginView`](#django.contrib.auth.views.LoginView)’s
`redirect_authenticated_user=True` and the logged-in user doesn’t have
all of the required permissions.

#### O `PermissionRequiredMixin` mixin

Para aplicar verificações de permissões a [“views” baseadas em classes](/pt-br/4.0/ref/class-based-views/), você pode usar o `PermissionRequiredMixin`:

#### `class PermissionRequiredMixin`

Este “mixin”, tal como o decorador `permission_required`, verifica se o usuário que está acessando a “view” tem todas as permissões. Você deve especificar as permissões (ou um iterável de permissões) usando o parâmetro `permission_required`:

```
from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.add_choice'
    # Or multiple of permissions:
    permission_required = ('polls.view_choice', 'polls.change_choice')
```

Você pode definir qualquer um dos parâmetros da [`AccessMixin`](#django.contrib.auth.mixins.AccessMixin) para personalizar o tratamento de usuários não autorizados.

Você pode também sobrescrever estes métodos:

#### `get_permission_required()`

Retorna um iterável de nomes de permissões usados pelo “mixin”. O padrão é o que está definido no atributo `permission_required`, convertido para uma tupla se necessário.

#### `has_permission()`

Retorna um booleano informando se o usuário corrente tem permissão para executar a “view” decorada. Por padrão, ele retorna o resultado da chamado do [`has_perms()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perms) com uma lista de permissões retornada pelo [`get_permission_required()`](#django.contrib.auth.mixins.PermissionRequiredMixin.get_permission_required).

### Redirecionando requisições não autorizadas em “views” baseadas em classes

To ease the handling of access restrictions in [class-based views](/pt-br/4.0/ref/class-based-views/), the `AccessMixin` can be used to configure
the behavior of a view when access is denied. Authenticated users are denied
access with an HTTP 403 Forbidden response. Anonymous users are redirected to
the login page or shown an HTTP 403 Forbidden response, depending on the
[`raise_exception`](#django.contrib.auth.mixins.AccessMixin.raise_exception) attribute.

#### `class AccessMixin`

#### `login_url`

O valor padrão retornado pelo [`get_login_url()`](#django.contrib.auth.mixins.AccessMixin.get_login_url).  O padrão é `None` e neste caso o [`get_login_url()`](#django.contrib.auth.mixins.AccessMixin.get_login_url) vai retornar o que estiver definido em [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL).

#### `permission_denied_message`

Valor padrão retornado por [`get_permission_denied_message()`](#django.contrib.auth.mixins.AccessMixin.get_permission_denied_message). O padrão original é uma string vazia.

#### `redirect_field_name`

Valor padrão retornado por  [`get_redirect_field_name()`](#django.contrib.auth.mixins.AccessMixin.get_redirect_field_name). Padrão original é `"next"`.

#### `raise_exception`

If this attribute is set to `True`, a
[`PermissionDenied`](/pt-br/4.0/ref/exceptions/#django.core.exceptions.PermissionDenied) exception is raised
when the conditions are not met.  When `False` (the default),
anonymous users are redirected to the login page.

#### `get_login_url()`

Retorna a URL para qual usuários que não passam no teste serão redirecionados. Retorna [`login_url`](#django.contrib.auth.mixins.AccessMixin.login_url) se estiver definido, ou caso contrário [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL).

#### `get_permission_denied_message()`

Quando [`raise_exception`](#django.contrib.auth.mixins.AccessMixin.raise_exception) for `True` (verdadeiro), este método poderá ser usado para controlar a mensagem de erro que será enviada ao manipulador de erros (error handler), para que ele a exiba para o usuário.
Por padrão, esse método retorna [`permission_denied_message`](#django.contrib.auth.mixins.AccessMixin.permission_denied_message)

#### `get_redirect_field_name()`

Retorna o nome do parâmetro de consulta (query) que terá a URL para onde o usuário será redirecionado, depois de ter logado com sucesso. Se você o setar como “None”, o parâmetro de consulta (query) não será adicionado.
Retorna [`redirect_field_name`](#django.contrib.auth.mixins.AccessMixin.redirect_field_name) attribute por padrão.

#### `handle_no_permission()`

Dependendo do valor de `raise_exception`, ou o método irá levantar a seguinte exeção: ``,:exc:`~django.core.exceptions.PermissionDenied` exception``, ou então, o método redirecionará o usuário para a `login_url`, podendo, opcionalmente, incluir o `redirect_field_name`, caso ele esteja definido.

#### Invalidação de Sessão após a Troca de Senha.

Se a classe definida em [`AUTH_USER_MODEL`](/pt-br/4.0/ref/settings/#std-setting-AUTH_USER_MODEL) herda de [`AbstractBaseUser`](/pt-br/4.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser) ou implementa seu próprio método [`get_session_auth_hash()`](/pt-br/4.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash), as sessões que forem autenticadas incluirão o “hash” retornado pelo método. No caso do [`AbstractBaseUser`](/pt-br/4.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser), o valor do “hash” é um HMAC da senha. O O Django verifica o “hash” na sessão para cada requisição comparando com o “hash” calculado durante a requisição. Isso permite ao usuário cancelar sua autenticação de todas as suas sessões quando altera sua senha.

The default password change views included with Django,
[`PasswordChangeView`](#django.contrib.auth.views.PasswordChangeView) and the
`user_change_password` view in the [`django.contrib.auth`](/pt-br/4.0/topics/auth/#module-django.contrib.auth) admin, update
the session with the new password hash so that a user changing their own
password won’t log themselves out. If you have a custom password change view
and wish to have similar behavior, use the [`update_session_auth_hash()`](#django.contrib.auth.update_session_auth_hash)
function.

#### `update_session_auth_hash(request, user)`

This function takes the current request and the updated user object from
which the new session hash will be derived and updates the session hash
appropriately. It also rotates the session key so that a stolen session
cookie will be invalidated.

Exemplo de uso:

```
from django.contrib.auth import update_session_auth_hash

def password_change(request):
    if request.method == 'POST':
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...
```

> **Note**
>
> [`get_session_auth_hash()`](/pt-br/4.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash) é baseado em [`SECRET_KEY`](/pt-br/4.0/ref/settings/#std-setting-SECRET_KEY). Sendo assim, você invalidará todas as sessões existentes, sempre que atualizar seu site para utilizar um novo segredo.

### Views de autenticação

O Django disponibiliza várias views que você pode utilizar para lidar com login (autenticação), logout (saída), e alteração de senhas. Essas views fazem uso dos [stock auth forms](#built-in-auth-forms), porém, você pode passar/utilizar seus próprios forms (formulários), caso prefira.

O Django não disponibiliza um template padrão para as views de autenticação. Você deve criar seus próprios templates para as views que quiser uitlizar. O contexto do template está documentado em cada view. veja: [Todas as views de autenticação](#all-authentication-views).

#### Usando as views

Existem formas diferentes de implementar essas views em seu projeto. A mais fácil delas é: incluir a URLconf disponível em `django.contrib.auth.urls` dentro da sua própria URLconf. Por exemplo:

```
urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
]
```

Isto incluirá os seguintes padrões de URL:

```
accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']
```

As views disponibilizam um nome de URL, para serem referênciadas com mais facilidade. Veja  [the URL documentation](/pt-br/4.0/topics/http/urls/) para mais detalhes sobre como usar padrões de URL nomeados.

Caso queira ter mais controle sobre suas URLs, você pode referenciar uma view específica em seu URLconf:

```
from django.contrib.auth import views as auth_views

urlpatterns = [
    path('change-password/', auth_views.PasswordChangeView.as_view()),
]
```

As views tem argumentos opcionais que podem ser utilizados para  alterar o comportamento delas. Por exemplo, para mudar o nome do template de uma view, basta passar o argumento `template_name`. Uma maneira de fazer isso, é colocando kwargs (argumentos de palvras chave) no seu URLconf. Estes argumentos serão passados para a view. Por exemplo:

```
urlpatterns = [
    path(
        'change-password/',
        auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
    ),
]
```

All views are [class-based](/pt-br/4.0/topics/class-based-views/), which allows
you to easily customize them by subclassing.

#### Todas as views de autenticação

Essa é uma lista com todas as views que `django.contrib.auth` disponibiliza. Para detalhes de implementação, veja [Usando as views](#using-the-views).

#### `class LoginView`

**Nome da URL:** `login`

Para detalhes sobre como usar padrões de URLs nomeadas, veja: [the URL documentation](/pt-br/4.0/topics/http/urls/)

**Métodos e Atributos**

#### `template_name`

The name of a template to display for the view used to log the user in.
Defaults to `registration/login.html`.

#### `next_page`

> **New in Django 4.0**

The URL to redirect to after login. Defaults to
[`LOGIN_REDIRECT_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_REDIRECT_URL).

#### `redirect_field_name`

The name of a `GET` field containing the URL to redirect to after
login. Defaults to `next`. Overrides the
[`get_default_redirect_url()`](#django.contrib.auth.views.LoginView.get_default_redirect_url) URL if the given `GET` parameter is
passed.

#### `authentication_form`

A callable (typically a form class) to use for authentication. Defaults
to [`AuthenticationForm`](#django.contrib.auth.forms.AuthenticationForm).

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `redirect_authenticated_user`

A boolean that controls whether or not authenticated users accessing
the login page will be redirected as if they had just successfully
logged in. Defaults to `False`.

> **Warning**
>
> Se você habilitar o `redirect_authenticated_user`, outros websites podem ser capazes de determinar se os visitantes estão autenticados no seu site solicitando URLs de redirecionamento para arquivos de imagem no seu site. Para evitar esse vazamento de informações de “[impressões digitais em midias sociais](https://robinlinus.github.io/socialmedia-leak)”, hospede todas as imagens e seu favicon em um domínio separado.
>
> Enabling `redirect_authenticated_user` can also result in a
> redirect loop when using the [`permission_required()`](#django.contrib.auth.decorators.permission_required) decorator
> unless the `raise_exception` parameter is used.

#### `success_url_allowed_hosts`

A [`set`](https://docs.python.org/3/library/stdtypes.html#set) of hosts, in addition to [`request.get_host()`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.get_host), that are safe for redirecting
after login. Defaults to an empty [`set`](https://docs.python.org/3/library/stdtypes.html#set).

#### `get_default_redirect_url()`

> **New in Django 4.0**

Returns the URL to redirect to after login. The default implementation
resolves and returns [`next_page`](#django.contrib.auth.views.LoginView.next_page) if set, or
[`LOGIN_REDIRECT_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_REDIRECT_URL) otherwise.

Isto é o que “LoginView” faz:

- Se for chamado via `GET`, ele mostrará um formulário de login que enviará um POST para a mesma URL. Explicaremos isso melhor em um instante.
- Se for chamado via `POST`, com as credenciais enviadas pelo usuário, ele vai tentar logar o usuário. Se o login der certo, a view irá redirecionar para a URL especificada em `next`. Se `next` não tiver sido definido, então a view redirecionará para [`settings.LOGIN_REDIRECT_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_REDIRECT_URL) (which defaults to `/accounts/profile/`). Se o login não der certo, o formulário de login será exibido novamente.

A responsabilidade de colocar o html, para o template de login, é toda sua. Esse template se chama `registration/login.html` por padrão. Ele recebe 4 variáveis de contexto de template.

- `form`: Um objeto [`Form`](/pt-br/4.0/ref/forms/api/#django.forms.Form) que representa a [`AuthenticationForm`](#django.contrib.auth.forms.AuthenticationForm).
- `next`: A  URL para a qual será redirecionado depois de uma autenticação bem sucedida. Esta pode conter também uma “query string”.
- `site`: A current [`Site`](/pt-br/4.0/ref/contrib/sites/#django.contrib.sites.models.Site) atual, de acordo com a configuração [`SITE_ID`](/pt-br/4.0/ref/settings/#std-setting-SITE_ID). Se você não tiver o framework de sites instalado, então `site` será definido como uma instância da classe of [`RequestSite`](/pt-br/4.0/ref/contrib/sites/#django.contrib.sites.requests.RequestSite), que pegará o nome e o domínio do site da [`HttpRequest`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest) atual.
- `site_name`: Um alias/atalho para `site.name`.  Se você não tiver o framework de sites instalado, então `site_name` receberá o valor de de [`request.META['SERVER_NAME']`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.META). Para mais informações sobre sites, veja [The “sites” framework](/pt-br/4.0/ref/contrib/sites/).

Caso prefira não chamar o template , você pode passar o parâmetro `template_name` como argumento extra para o método as\_view\` na sua URLconf. Por exemplo, esta linha URLconf usaria  como alternativa:

```
path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),
```

Você também pode escolher o nome do campo `GET` que contém a URL para redirecionar após o login usando `redirect_field_name`. Por padrão, o campo é chamado de `next`.

Você pode usar o seguinte exemplo de template `registration/login.html` como ponto de partida. Esse exemplo assume que você tenha um template `base.html` que defina um bloco `content`:

```html+django
{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>

{# Assumes you set up the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}
```

If you have customized authentication (see [Customizing Authentication](/pt-br/4.0/topics/auth/customizing/)) you can use a custom authentication form by
setting the `authentication_form` attribute. This form must accept a
`request` keyword argument in its `__init__()` method and provide a
`get_user()` method which returns the authenticated user object (this
method is only ever called after successful form validation).

#### `class LogoutView`

Desloga um usuário.

**Nome da URL:** `logout`

**Atributos:**

#### `next_page`

The URL to redirect to after logout. Defaults to
[`LOGOUT_REDIRECT_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGOUT_REDIRECT_URL).

#### `template_name`

The full name of a template to display after logging the user out.
Defaults to `registration/logged_out.html`.

#### `redirect_field_name`

The name of a `GET` field containing the URL to redirect to after log
out. Defaults to `'next'`. Overrides the
[`next_page`](#django.contrib.auth.views.LogoutView.next_page) URL if the given `GET` parameter is
passed.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `success_url_allowed_hosts`

A [`set`](https://docs.python.org/3/library/stdtypes.html#set) of hosts, in addition to [`request.get_host()`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.get_host), that are safe for redirecting
after logout. Defaults to an empty [`set`](https://docs.python.org/3/library/stdtypes.html#set).

**Contexto de Template:**

- `title`: Versão localizada da string “Logged out” (deslogado). Ou seja, você pode substituir “Logged out” por uma versão traduziada (como deslogado) para o idioma que desejar.
- `site`: A current [`Site`](/pt-br/4.0/ref/contrib/sites/#django.contrib.sites.models.Site) atual, de acordo com a configuração [`SITE_ID`](/pt-br/4.0/ref/settings/#std-setting-SITE_ID). Se você não tiver o framework de sites instalado, então `site` será definido como uma instância da classe of [`RequestSite`](/pt-br/4.0/ref/contrib/sites/#django.contrib.sites.requests.RequestSite), que pegará o nome e o domínio do site da [`HttpRequest`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest) atual.
- `site_name`: Um alias/atalho para `site.name`.  Se você não tiver o framework de sites instalado, então `site_name` receberá o valor de de [`request.META['SERVER_NAME']`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.META). Para mais informações sobre sites, veja [The “sites” framework](/pt-br/4.0/ref/contrib/sites/).

#### `logout_then_login(request, login_url=None)`

Desloga um usuário e redireciona para a página de login.

**Nome da URL:** não é fornecido uma URL padrão.

**Argumentos opcionais:**

- `login_url`: a URL da página de login, para onde o usuário deve ser redirecionado.  Caso esse parâmetro não seja passado, ele irá tomar o o valor [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL)  por padrão.

#### `class PasswordChangeView`

**Nome da URL:** `password_change`

Permite a um usuário alterar sua senha.

**Atributos:**

#### `template_name`

The full name of a template to use for displaying the password change
form. Defaults to `registration/password_change_form.html` if not
supplied.

#### `success_url`

The URL to redirect to after a successful password change. Defaults to
`'password_change_done'`.

#### `form_class`

A custom “change password” form which must accept a `user` keyword
argument. The form is responsible for actually changing the user’s
password. Defaults to
[`PasswordChangeForm`](#django.contrib.auth.forms.PasswordChangeForm).

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

**Contexto de Template:**

- `form`: The password change form (see `form_class` above).

#### `class PasswordChangeDoneView`

**Nome da URL:** `password_change_done`

A pagina que é exibida após um usuário ter alterado sua senha.

**Atributos:**

#### `template_name`

The full name of a template to use. Defaults to
`registration/password_change_done.html` if not supplied.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `class PasswordResetView`

**Nome da URL:** `password_reset`

Gera um link de uso único, que permite o usuário cadastrar uma nova senha. Esse link será enviado para o e-mail do usuário.

This view will send an email if the following conditions are met:

- The email address provided exists in the system.
- The requested user is active (`User.is_active` is `True`).
- The requested user has a usable password. Users flagged with an unusable
  password (see
  [`set_unusable_password()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.set_unusable_password)) aren’t
  allowed to request a password reset to prevent misuse when using an
  external authentication source like LDAP.

If any of these conditions are *not* met, no email will be sent, but the
user won’t receive any error message either. This prevents information
leaking to potential attackers. If you want to provide an error message in
this case, you can subclass
[`PasswordResetForm`](#django.contrib.auth.forms.PasswordResetForm) and use the
`form_class` attribute.

> **Note**
>
> Be aware that sending an email costs extra time, hence you may be
> vulnerable to an email address enumeration timing attack due to a
> difference between the duration of a reset request for an existing
> email address and the duration of a reset request for a nonexistent
> email address. To reduce the overhead, you can use a 3rd party package
> that allows to send emails asynchronously, e.g. [django-mailer](https://pypi.org/project/django-mailer/).

**Atributos:**

#### `template_name`

The full name of a template to use for displaying the password reset
form. Defaults to `registration/password_reset_form.html` if not
supplied.

#### `form_class`

Form that will be used to get the email of the user to reset the
password for. Defaults to
[`PasswordResetForm`](#django.contrib.auth.forms.PasswordResetForm).

#### `email_template_name`

The full name of a template to use for generating the email with the
reset password link. Defaults to
`registration/password_reset_email.html` if not supplied.

#### `subject_template_name`

The full name of a template to use for the subject of the email with
the reset password link. Defaults to
`registration/password_reset_subject.txt` if not supplied.

#### `token_generator`

Instance of the class to check the one time link. This will default to
`default_token_generator`, it’s an instance of
`django.contrib.auth.tokens.PasswordResetTokenGenerator`.

#### `success_url`

The URL to redirect to after a successful password reset request.
Defaults to `'password_reset_done'`.

#### `from_email`

A valid email address. By default Django uses the
[`DEFAULT_FROM_EMAIL`](/pt-br/4.0/ref/settings/#std-setting-DEFAULT_FROM_EMAIL).

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `html_email_template_name`

The full name of a template to use for generating a
`text/html` multipart email with the password reset link. By
default, HTML email is not sent.

#### `extra_email_context`

A dictionary of context data that will be available in the email
template. It can be used to override default template context values
listed below e.g. `domain`.

**Contexto de Template:**

- `form`: The form (see `form_class` above) for resetting the user’s
  password.

**O contexto do template do email:**

- `email`: um apelido para `user.email`
- `user`: o usuário do tipo [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User), de acordo com o campo do `email` do formulário. Somente usuários ativos conseguem resetar suas senhas (`User.is_active is True`).
- `site_name`: Um alias/atalho para `site.name`.  Se você não tiver o framework de sites instalado, então `site_name` receberá o valor de de [`request.META['SERVER_NAME']`](/pt-br/4.0/ref/request-response/#django.http.HttpRequest.META). Para mais informações sobre sites, veja [The “sites” framework](/pt-br/4.0/ref/contrib/sites/).
- `domain`: um apelido para `site.domain`. Se você não tem o framework “site” instalado, este parâmetro será setado com o valor do `request.get_host()`.
- `protocol`: http ou https
- `uid`: a chave primária do usuário codificada em base 64
- `token`: o “Token” para verificar se o link de reset é valido.

Exemplo de `registration/password_reset_email.html` (template do corpo do email):

```html+django
Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
```

O mesmo contexto de template é usado para o template do assunto. O assunto de ser uma única em uma string de texto plano.

#### `class PasswordResetDoneView`

**Nome da URL:** `password_reset_done`

The page shown after a user has been emailed a link to reset their
password. This view is called by default if the [`PasswordResetView`](#django.contrib.auth.views.PasswordResetView)
doesn’t have an explicit `success_url` URL set.

> **Note**
>
> Se o endereço de email não existir no sistema, ou o usuário for inativo, ou ainda se a senha é inutilizável, o usuário será redirecionado para esta “view” mas nenhum email será enviado.

**Atributos:**

#### `template_name`

The full name of a template to use. Defaults to
`registration/password_reset_done.html` if not supplied.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `class PasswordResetConfirmView`

**Nome da URL:** `password_reset_confirm`

Apresenta uma formulário para informar uma nova senha.

**Argumentos palavra-chave da URL:**

- `uidb64`: The user’s id encoded in base 64.
- `token`: Token to check that the password is valid.

**Atributos:**

#### `template_name`

The full name of a template to display the confirm password view.
Default value is `registration/password_reset_confirm.html`.

#### `token_generator`

Instance of the class to check the password. This will default to
`default_token_generator`, it’s an instance of
`django.contrib.auth.tokens.PasswordResetTokenGenerator`.

#### `post_reset_login`

A boolean indicating if the user should be automatically authenticated
after a successful password reset. Defaults to `False`.

#### `post_reset_login_backend`

A dotted path to the authentication backend to use when authenticating
a user if `post_reset_login` is `True`. Required only if you have
multiple [`AUTHENTICATION_BACKENDS`](/pt-br/4.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) configured. Defaults to
`None`.

#### `form_class`

Form that will be used to set the password. Defaults to
[`SetPasswordForm`](#django.contrib.auth.forms.SetPasswordForm).

#### `success_url`

URL to redirect after the password reset done. Defaults to
`'password_reset_complete'`.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

#### `reset_url_token`

Token parameter displayed as a component of password reset URLs.
Defaults to `'set-password'`.

**Contexto de Template:**

- `form`: The form (see `form_class` above) for setting the new user’s
  password.
- `validlink`: Boolenano, verdadeiro se o link (combinação de `uidb64` e `token`) é válido ou ainda não utilizado.

#### `class PasswordResetCompleteView`

**Nome da URL:** `password_reset_complete`

Apresentando a “view” a qual informa ao usuário que sua senha foi alterada com sucesso.

**Atributos:**

#### `template_name`

The full name of a template to display the view. Defaults to
`registration/password_reset_complete.html`.

#### `extra_context`

A dictionary of context data that will be added to the default context
data passed to the template.

### Funções auxiliares

#### `redirect_to_login(next, login_url=None, redirect_field_name='next')`

Redireciona para a página de autenticação, e então retornar a outra URL depois de uma autenticação com sucesso.

**Argumentos requeridos:**

- `next`: URL para a qual é redirecionado depois de uma autenticação bem sucedida.

**Argumentos opcionais:**

- `login_url`: a URL da página de login, para onde o usuário deve ser redirecionado.  Caso esse parâmetro não seja passado, ele irá tomar o o valor [`settings.LOGIN_URL`](/pt-br/4.0/ref/settings/#std-setting-LOGIN_URL)  por padrão.
- `redirect_field_name`: o nome de um campo `GET` contendo a URL para a qual é redirecionado depois de finalizar a seção autenticada. Substitui o `next` se o dado parâmetro do `GET` for passado.

### Formulários embutidos

Caso não queira utilizar a “views” embutidas no Django, mas quer a conveniência de não escrever formulários para esta funcionalidade, o sistema de autenticação fornece vários formulários prontos localizados em [`django.contrib.auth.forms`](#module-django.contrib.auth.forms):

> **Note**
>
> The built-in authentication forms make certain assumptions about the user
> model that they are working with. If you’re using a [custom user model](/pt-br/4.0/topics/auth/customizing/#auth-custom-user), it may be necessary to define your own forms for the
> authentication system. For more information, refer to the documentation
> about [using the built-in authentication forms with custom user models](/pt-br/4.0/topics/auth/customizing/#custom-users-and-the-built-in-auth-forms).

#### `class AdminPasswordChangeForm`

Um formulário usado na interface do “admin” para alterar a senha do usuário.

Recebe o `user` como primeiro argumento posicional.

#### `class AuthenticationForm`

Um formulário para autenticar o usuário.

Recebe o `request` como seu primeiro parâmetro posicional, o qual é armazenado na instância do formulário para ser usado pelas sub-classes.

#### `confirm_login_allowed(user)`

Por padrão, o `AuthenticationForm` rejeita usuários que tenham o indicador `is_active` definido como `False`. Você pode alterar este comportamento com uma regra personalizada para determinar quais usuários podem se autenticar. Faça isso com um formulário personalizado que herda a `AuthenticationForm` e sobreescreve o método `confirm_login_allowed()`. Este método deve emitir uma [`ValidationError`](/pt-br/4.0/ref/exceptions/#django.core.exceptions.ValidationError) se o usuário fornecido não deve ser autenticado.

Por exemplo, para permitir que todos os usuários se autentiquem independente do status “active”:

```
from django.contrib.auth.forms import AuthenticationForm

class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
    def confirm_login_allowed(self, user):
        pass
```

(In this case, you’ll also need to use an authentication backend that
allows inactive users, such as
[`AllowAllUsersModelBackend`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.backends.AllowAllUsersModelBackend).)

Ou para permitir somente alguns usuários ativos a se autenticarem:

```
class PickyAuthenticationForm(AuthenticationForm):
    def confirm_login_allowed(self, user):
        if not user.is_active:
            raise ValidationError(
                _("This account is inactive."),
                code='inactive',
            )
        if user.username.startswith('b'):
            raise ValidationError(
                _("Sorry, accounts starting with 'b' aren't welcome here."),
                code='no_b_users',
            )
```

#### `class PasswordChangeForm`

Um formulário para permitir que o usuário altere sua senha.

#### `class PasswordResetForm`

Um formulário para gerar e enviar um email com um link de uso único para resetar a senha do usuário.

#### `send_mail(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)`

Usa os argumentos para enviar um  `EmailMultiAlternatives`. Pode ser sobrescrito para personalizar como o email é enviado para o usuário.

**Parâmetros:** - `subject_template_name` – O template para o assunto.
- `email_template_name` – O template para o corpo do email.
- `context` – O contexto passado para o `subject_template`, `email_template`, e para o `html_email_template` (se não for `None`).
- `from_email` – O email do remetente.
- `to_email` – O email do usuário que requisitou.
- `html_email_template_name` – O template para o corpo HTML; o valor padrão é `None`, neste caso um email com texto plano sem marcação é enviado.

By default, `save()` populates the `context` with the
same variables that
[`PasswordResetView`](#django.contrib.auth.views.PasswordResetView) passes to its
email context.

#### `class SetPasswordForm`

Um formulário que permite ao usuário alterar sua senha sem informar a senha antiga.

#### `class UserChangeForm`

Um formulário usado na interface de administração para alterar informações e permissões do usuário.

#### `class UserCreationForm`

Uma [`ModelForm`](/pt-br/4.0/topics/forms/modelforms/#django.forms.ModelForm) para criar um novo usuário.

Ela tem três campos: `username` (vindo o modelo do usuário), `password1`, e `password2`. Ela verifica se o `password1` e o `password2` combinam, validando a senha usando a [`validate_password()`](/pt-br/4.0/topics/auth/passwords/#django.contrib.auth.password_validation.validate_password), e define a senha do usuário usando o [`set_password()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.set_password).

### Dados de autenticação nos templates.

O usuário atualmente autenticado e suas permissões são disponibilizadas no [contexto do template](/pt-br/4.0/ref/templates/api/) quando você usa a [`RequestContext`](/pt-br/4.0/ref/templates/api/#django.template.RequestContext).

> **Tecnicidades**
>
> Tecnicamente, estas variáveis somente ficam disponíveis no contexto do template quando se usa a [`RequestContext`](/pt-br/4.0/ref/templates/api/#django.template.RequestContext) e o processador de contexto `'django.contrib.auth.context_processors.auth'`  estiver habilitado. Ele está no arquivo de definições gerado normalmente. Para mais detalhes, veja os [documentos de RequestContext](/pt-br/4.0/ref/templates/api/#subclassing-context-requestcontext).

#### Usuários

Quando a [`RequestContext`](/pt-br/4.0/ref/templates/api/#django.template.RequestContext) renderiza um template, o usuário autenticado no momento, seja uma instância de [`User`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User) ou uma instância de [`AnonymousUser`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser), são armazenadas em uma variável de template chamada `{{ user }}`:

```html+django
{% if user.is_authenticated %}
    <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
    <p>Welcome, new user. Please log in.</p>
{% endif %}
```

Esta variável de template não está disponível se um `RequestContext` não for usado.

#### Permissões

As permissões do usuário autenticado são armazenadas na variável `{{ perms }}` do template. Isso é uma instância de `django.contrib.auth.context_processors.PermWrapper`, o qual é um “proxy” de permissões amigável ao template.

Evaluating a single-attribute lookup of `{{ perms }}` as a boolean is a proxy
to [`User.has_module_perms()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.has_module_perms). For example, to check if
the logged-in user has any permissions in the `foo` app:

```
{% if perms.foo %}
```

Evaluating a two-level-attribute lookup as a boolean is a proxy to
[`User.has_perm()`](/pt-br/4.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perm). For example,
to check if the logged-in user has the permission `foo.add_vote`:

```
{% if perms.foo.add_vote %}
```

Here’s a more complete example of checking permissions in a template:

```html+django
{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.add_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.add_driving %}
        <p>You can drive!</p>
    {% endif %}
{% else %}
    <p>You don't have permission to do anything in the foo app.</p>
{% endif %}
```

É possível também conferir as permissões através das declarações “{% if in %}”. Por exemplo:

```html+django
{% if 'foo' in perms %}
    {% if 'foo.add_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}
```

## Gerenciando usuários no admin

Quando você tem instalados “django.contrib.admin” e “django.contrib.auth”, o admin provides um jeito conveniente de visualizar e gerenciar usuários, grupos e permissões. Usuários podem ser criados e deletados como qualquer modelo Django. Grupos podem ser criados, e permissões podem ser dadas a usuários ou grupos. Um registro das edições dos usuários aos modelos é criado no admin e também é armazenado e exibido.

### Criando usuários

Você verá um link para “Usuários” na seção “Autenticação” da página principal do admin. A página “Adicionar usuário” do admin é diferente das outras páginas do admin pois exige que se escolha um nome de usuário e senha antes de permitir que se edite o resto dos campos de usuário.

Também observe: se você quer que uma conta de usuário possa criar usuários usando o site do Django admin, você precisará dar permissão para que essa conta adicione usuários *e* modifique usuários (por exemplo, as permissões “Adicionar usuário” e “Modificar usuário”). Se uma conta tem a permissão de adicionar usuários, mas não de modificá-los, então a conta não poderá adicionar usuários. Por quê? Porque se você tem permissão de adicionar usuários, você tem poder de criar superusuários, que pode, então, criar outros usuários. Então o Django exige permissões para adicionar *e* modificar como uma leve medida de segurança.

Seja consciente sobre como você permite aos usuários que gerenciem as permissões. Se você dá a habilidade de editar usuários a um não superusuário, isso, em última instância, é o mesmo que dá-lo a condição de superusuário, já que ele poderá elevar permissões de usuários, inclusive dele mesmo!

### Mudando as senhas

Senhas de usuários não são exibidas no admin (nem armazenadas no banco de dados). Mas as :doc:’password storage details \</topic/auth/passwords\>’ são exibidas. Incluído na exibição dessas informações, há um link para um formulário de modificação de senha que permite que admins mudem a senha de usuários.