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 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() and login(): authenticate() sets the user.backend attribute on the user object it returns.
3. Use o backend no 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), e não a classe de “backend” atual.

A maneira padrão¶

The raw way to limit access to pages is to check request.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(f"{settings.LOGIN_URL}?next={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()

from django.contrib.auth.decorators import login_required


@login_required
def my_view(request):
    ...

A login_required() faz o seguinte:

• Se o usuário não registrou seu acesso, redireciona para settings.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() 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() 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 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 também aceita nome de funções “view”e named URL patterns. Isso permite a você mapear livremente sua “view” de login dentro do URconf sem ter que atualizar o arquivo de definições.

The LoginRequiredMixin mixin¶

Quando usar 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.

Você pode definir qualquer dos parâmetros da 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"

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 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() recebe um argumento obrigatório: um executável que recebe um objeto do tipo User e retorna True se é permitido ao usuário acessar a página. Note que a user_passes_test() não verifica automaticamente se o User não é anônimo.

A 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 se você não especificar nenhum.

redirect_field_name

O mesmo que 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, 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 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()).

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().:

from django.contrib.auth.decorators import permission_required


@permission_required("polls.add_choice")
def my_view(request):
    ...

Just like the 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() 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(), o padrão para login_url é a definição de settings.LOGIN_URL.

Se o parâmetro raise_exception é fornecido, o decorador irá emitir um PermissionDenied, mostrando o the 403 (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():

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’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, 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 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() com uma lista de permissões retornada pelo get_permission_required().

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

Se a classe definida em AUTH_USER_MODEL herda de AbstractBaseUser ou implementa seu próprio método get_session_auth_hash(), as sessões que forem autenticadas incluirão o “hash” retornado pelo método. No caso do 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 and the user_change_password view in the 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() 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:
        ...

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")),
]

This will include the following URL patterns:

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 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, 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.

class LoginView¶

Nome da URL: login

Para detalhes sobre como usar padrões de URLs nomeadas, veja: the URL documentation

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¶

The URL to redirect to after login. Defaults to 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() URL if the given GET parameter is passed.

authentication_form¶

A callable (typically a form class) to use for authentication. Defaults to 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.

Aviso

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”, 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() decorator unless the raise_exception parameter is used.

success_url_allowed_hosts¶

A set of hosts, in addition to request.get_host(), that are safe for redirecting after login. Defaults to an empty set.

get_default_redirect_url()¶

Returns the URL to redirect to after login. The default implementation resolves and returns next_page if set, or 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 (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 que representa a 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 atual, de acordo com a configuração 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, que pegará o nome e o domínio do site da 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']. Para mais informações sobre sites, veja The “sites” framework.

Caso prefira não chamar o template :arquivo:`registration/login.html`, 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 :arquivo:`myapp/login.html` 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:

{% 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) 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¶

Logs a user out on POST requests.

Obsoleto desde a versão 4.1: Support for logging out on GET requests is deprecated and will be removed in Django 5.0.

Nome da URL: logout

Atributos:

next_page¶

The URL to redirect to after logout. Defaults to 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 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 of hosts, in addition to request.get_host(), that are safe for redirecting after logout. Defaults to an empty 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 atual, de acordo com a configuração 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, que pegará o nome e o domínio do site da 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']. Para mais informações sobre sites, veja The “sites” framework.

logout_then_login(request, login_url=None)¶

Logs a user out on POST requests, then redirects to the login page.

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 por padrão.

Obsoleto desde a versão 4.1: Support for logging out on GET requests is deprecated and will be removed in Django 5.0.

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.

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()) 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 and use the form_class attribute.

Nota

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.

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.

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.

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, 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']. Para mais informações sobre sites, veja The “sites” framework.
• 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):

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 doesn’t have an explicit success_url URL set.

Nota

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 configured. Defaults to None.

form_class¶

Form that will be used to set the password. Defaults to 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.

Usuários¶

Quando a RequestContext renderiza um template, o usuário autenticado no momento, seja uma instância de User ou uma instância de AnonymousUser, são armazenadas em uma variável de template chamada {{ user }}:

{% 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(). 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(). 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:

{% 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:

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