Usando o sistema de autenticação DjangoLink para este cabeçalho

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 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”Link para este cabeçalho

Os objetos do tipo 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' ou admin '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:

See the User API documentation for a complete reference. The documentation that follows is more task-oriented.

Criando usuáriosLink para este cabeçalho

The most direct way to create users is to use the included create_user() helper function:

Python console

>>> 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áriosLink para este cabeçalho

Create superusers using the createsuperuser command:

Linux / macOS

Shell

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

Windows

...\> py 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 ou --email, estes valores serão solicitados.

Mudando as senhasLink para este cabeçalho

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

You can also change a password programmatically, using set_password():

Python console

>>> 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áriosLink para este cabeçalho

authenticate(request=None, **credentials)Link para esta definição

aauthenticate(request=None, **credentials)Link para esta definição

Asynchronous version: aauthenticate()

Use authenticate() to verify a set of credentials. It takes credentials as keyword arguments, username and password for the default case, checks them against each authentication backend, and returns a User object if the credentials are valid for a backend. If the credentials aren’t valid for any backend or if a backend raises PermissionDenied, it returns None. For example:

Code

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 which is passed on the authenticate() method of the authentication backends.

Permissões e AutorizaçãoLink para este cabeçalho

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(), has_add_permission(), has_change_permission() and has_delete_permission() methods provided by the ModelAdmin class, it is possible to customize permissions for different object instances of the same type.

Os objetos da User tem dois campos muitos-para-muitos: groups e user_permissions. Os objetos do tipo User podem acessar seus objetos relacionados da mesma maneira que qualquer outro Django model:

Code

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ãoLink para este cabeçalho

When django.contrib.auth is listed in your 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; A primeira vez que você executa o migrate depois de adicionar o django.contrib.auth ao 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 (a função que cria as permissões está conectada ao sinal post_migrate).

When a model is renamed in an installed application, Django automatically updates the associated default permissions to match the new model name when you run manage.py migrate.

If a permission with the new codename already exists (for example, due to a leftover permission from a previous migration), Django raises an error with next steps.

Assumindo que você tenha uma aplicação com um 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 é raramente acessada diretamente.

The Permission model provides a helper property, user_perm_str, that returns the string representation that can be used to check permission using the has_perm() method.

GruposLink para este cabeçalho

Os modelos 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õesLink para este cabeçalho

Enquanto que as 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:

Code

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 através do seu atributo user_permissions ou para um Group através de seu atributo permissions.

Proxy models need their own content type

If you want to create permissions for a proxy model, pass for_concrete_model=False to ContentTypeManager.get_for_model() to get the appropriate ContentType:

Code

content_type = ContentType.objects.get_for_model(
    BlogPostProxy, for_concrete_model=False
)

Cache de permissõesLink para este cabeçalho

The 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:

Code

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 ProxyLink para este cabeçalho

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:

Code

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

Python console

>>> # 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 requestsLink para este cabeçalho

Django uses sessions and middleware to hook the authentication system into HttpRequest objects.

These provide a request.user attribute and a request.auser async method on every request which represents the current user. If the current user has not logged in, this attribute will be set to an instance of AnonymousUser, otherwise it will be an instance of User.

Você pode distinguí-los com is_authenticated, como a seguir:

Code

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

Or in an asynchronous view:

Code

user = await request.auser()
if user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

Como autenticar um usuárioLink para este cabeçalho

Caso queira adicionar um usuário autenticado à sessão atual - isto pode ser feito com a função login().

login(request, user, backend=None)Link para esta definição

alogin(request, user, backend=None)Link para esta definição

Asynchronous version: alogin()

To log a user in, from a view, use login(). It takes an HttpRequest object and a User object. login() saves the user’s ID in the session, using Django’s session framework.

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

This example shows how you might use both authenticate() and login():

Code

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çãoLink para este cabeçalho

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:

Usa o valor do argumento backend opcional, se fornecido.
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.
Use o backend no AUTHENTICATION_BACKENDS, se houver somente um.
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.

Como finalizar a sessão de um usuárioLink para este cabeçalho

logout(request)Link para esta definição

alogout(request)Link para esta definição

Asynchronous version: alogout()

To log out a user who has been logged in via django.contrib.auth.login(), use django.contrib.auth.logout() within your view. It takes an HttpRequest object and has no return value. Example:

Code

from django.contrib.auth import logout


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

Note that logout() doesn’t throw any errors if the user wasn’t logged in.

When you call 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().

Limitando o acesso de usuários authenticadosLink para este cabeçalho

A maneira padrãoLink para este cabeçalho

The raw way to limit access to pages is to check request.user.is_authenticated and either redirect to a login page:

Code

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:

Code

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` decoratorLink para este cabeçalho

login_required(redirect_field_name='next', login_url=None)Link para esta definição

Como atalho, você pode usar o decorador conveniente login_required()

Code

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:

Code

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:

Code

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:

Code

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` mixinLink para este cabeçalho

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 LoginRequiredMixinLink para esta definição

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:

Code

from django.contrib.auth.mixins import LoginRequiredMixin


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

The `login_not_required` decoratorLink para este cabeçalho

When LoginRequiredMiddleware is installed, all views require authentication by default. Some views, such as the login view, may need to disable this behavior.

login_not_required()Link para esta definição: Allows unauthenticated requests to this view when LoginRequiredMiddleware is installed.

Limitando o acesso de usuários autenticados que passam no teste.Link para este cabeçalho

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:

Code

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')Link para esta definição

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

Code

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:

Code

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

class UserPassesTestMixinLink para esta definição

Quando usar as “views” baseadas em classes, você pode usar o UserPassesTestMixin para isso.

test_func()Link para esta definição

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:

Code

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()Link para esta definição: 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:

Code

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` decoratorLink para este cabeçalho

permission_required(perm, login_url=None, raise_exception=False)Link para esta definição

It’s a relatively common task to check whether a user has a particular permission. For that reason, Django provides a shortcut for that case: the permission_required() decorator:

Code

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 that permission_required() also takes an optional login_url parameter:

Code

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

Code

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` mixinLink para este cabeçalho

Para aplicar verificações de permissões a “views” baseadas em classes, você pode usar o PermissionRequiredMixin:

class PermissionRequiredMixinLink para esta definição

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:

Code

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()Link para esta definição: 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()Link para esta definição: Returns a boolean denoting whether the current user has permission to execute the decorated view. By default, this returns the result of calling has_perms() with the list of permissions returned by get_permission_required().

Redirecionando requisições não autorizadas em “views” baseadas em classesLink para este cabeçalho

To ease the handling of access restrictions in 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 attribute.

class AccessMixinLink para esta definição

login_urlLink para esta definição: Default return value for get_login_url(). Defaults to None in which case get_login_url() falls back to settings.LOGIN_URL.

permission_denied_messageLink para esta definição: Valor padrão retornado por get_permission_denied_message(). O padrão original é uma string vazia.

redirect_field_nameLink para esta definição: Valor padrão retornado por get_redirect_field_name(). Padrão original é "next".

raise_exceptionLink para esta definição: If this attribute is set to True, a 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()Link para esta definição: Retorna a URL para qual usuários que não passam no teste serão redirecionados. Retorna login_url se estiver definido, ou caso contrário settings.LOGIN_URL.

get_permission_denied_message()Link para esta definição: Quando 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

get_redirect_field_name()Link para esta definição: 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 attribute por padrão.

handle_no_permission()Link para esta definição: 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.Link para este cabeçalho

If your AUTH_USER_MODEL inherits from AbstractBaseUser or implements its own get_session_auth_hash() method, authenticated sessions will include the hash returned by this function. In the AbstractBaseUser case, this is an HMAC of the password field. Django verifies that the hash in the session for each request matches the one that’s computed during the request. This allows a user to log out all of their sessions by changing their password.

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)Link para esta definição

aupdate_session_auth_hash(request, user)Link para esta definição

Asynchronous version: aupdate_session_auth_hash()

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:

Code

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

Views de autenticaçãoLink para este cabeçalho

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

Usando as viewsLink para este cabeçalho

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:

Code

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

This will include the following URL patterns:

Text

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:

Code

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:

Code

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çãoLink para este cabeçalho

Essa é uma lista com todas as views que django.contrib.auth disponibiliza. Para detalhes de implementação, veja Usando as views.

class LoginViewLink para esta definição

Nome da URL: login

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

Métodos e Atributos

template_nameLink para esta definição: The name of a template to display for the view used to log the user in. Defaults to registration/login.html.

next_pageLink para esta definição: The URL to redirect to after login. Defaults to LOGIN_REDIRECT_URL.

redirect_field_nameLink para esta definição: 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_formLink para esta definição: A callable (typically a form class) to use for authentication. Defaults to AuthenticationForm.

extra_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

redirect_authenticated_userLink para esta definição: 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_hostsLink para esta definição: 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()Link para esta definição: 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:

Code

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:

Django template

{% 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 LogoutViewLink para esta definição

Logs a user out on POST requests.

Nome da URL: logout

Atributos:

next_pageLink para esta definição: The URL to redirect to after logout. Defaults to LOGOUT_REDIRECT_URL.

template_nameLink para esta definição: The full name of a template to display after logging the user out. Defaults to registration/logged_out.html.

redirect_field_nameLink para esta definição: 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_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

success_url_allowed_hostsLink para esta definição: 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)Link para esta definição

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.

class PasswordChangeViewLink para esta definição

Nome da URL: password_change

Permite a um usuário alterar sua senha.

Atributos:

template_nameLink para esta definição: 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_urlLink para esta definição: The URL to redirect to after a successful password change. Defaults to 'password_change_done'.

form_classLink para esta definição: 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_contextLink para esta definição: 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 PasswordChangeDoneViewLink para esta definição

Nome da URL: password_change_done

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

Atributos:

template_nameLink para esta definição: The full name of a template to use. Defaults to registration/password_change_done.html if not supplied.

extra_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

class PasswordResetViewLink para esta definição

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.

Atributos:

template_nameLink para esta definição: 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_classLink para esta definição: Form that will be used to get the email of the user to reset the password for. Defaults to PasswordResetForm.

email_template_nameLink para esta definição: 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_nameLink para esta definição: 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_generatorLink para esta definição: 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_urlLink para esta definição: The URL to redirect to after a successful password reset request. Defaults to 'password_reset_done'.

from_emailLink para esta definição: A valid email address. By default Django uses the DEFAULT_FROM_EMAIL.

extra_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

html_email_template_nameLink para esta definição: 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_contextLink para esta definição: 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):

Django template

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 PasswordResetDoneViewLink para esta definição

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.

Atributos:

template_nameLink para esta definição: The full name of a template to use. Defaults to registration/password_reset_done.html if not supplied.

extra_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

class PasswordResetConfirmViewLink para esta definição

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_nameLink para esta definição: The full name of a template to display the confirm password view. Default value is registration/password_reset_confirm.html.

token_generatorLink para esta definição: 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_loginLink para esta definição: A boolean indicating if the user should be automatically authenticated after a successful password reset. Defaults to False.

post_reset_login_backendLink para esta definição: 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_classLink para esta definição: Form that will be used to set the password. Defaults to SetPasswordForm.

success_urlLink para esta definição: URL to redirect after the password reset done. Defaults to 'password_reset_complete'.

extra_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

reset_url_tokenLink para esta definição: 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 PasswordResetCompleteViewLink para esta definição

Nome da URL: password_reset_complete

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

Atributos:

template_nameLink para esta definição: The full name of a template to display the view. Defaults to registration/password_reset_complete.html.

extra_contextLink para esta definição: A dictionary of context data that will be added to the default context data passed to the template.

Funções auxiliaresLink para este cabeçalho

redirect_to_login(next, login_url=None, redirect_field_name='next')Link para esta definição

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 por padrão.
redirect_field_name: The name of a GET field containing the URL to redirect to after login. Overrides next if the given GET parameter is passed.

Formulários embutidosLink para este cabeçalho

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:

class AdminPasswordChangeFormLink para esta definição

A form used in the admin interface to change a user’s password, including the ability to set an unusable password (via set_unusable_password()), which blocks the user from logging in with password-based authentication.

Recebe o user como primeiro argumento posicional.

class AdminUserCreationFormLink para esta definição

A form used in the admin interface to create a new user. Inherits from UserCreationForm.

It includes an additional usable_password field, enabled by default. If usable_password is enabled, it verifies that password1 and password2 are non empty and match, validates the password using validate_password(), and sets the user’s password using set_password(). If usable_password is disabled, no password validation is done, and password-based authentication is disabled for the user by calling set_unusable_password().

class AuthenticationFormLink para esta definição

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)Link para esta definição

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 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”:

Code

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

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

Code

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 BaseUserCreationFormLink para esta definição

A ModelForm for creating a new user. This is the recommended base class if you need to customize the user creation form.

It has three fields: username (from the user model), password1, and password2. It verifies that password1 and password2 match, validates the password using validate_password(), and sets the user’s password using set_password().

class PasswordChangeFormLink para esta definição: Um formulário para permitir que o usuário altere sua senha.

class PasswordResetFormLink para esta definição

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)Link para esta definição

Uses the arguments to send an EmailMultiAlternatives. Can be overridden to customize how the email is sent to the user. If you choose to override this method, be mindful of handling potential exceptions raised due to email sending failures.

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 passes to its email context.

class SetPasswordFormLink para esta definição: Um formulário que permite ao usuário alterar sua senha sem informar a senha antiga.

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

class UserCreationFormLink para esta definição: Inherits from BaseUserCreationForm. To help prevent confusion with similar usernames, the form doesn’t allow usernames that differ only in case.

Dados de autenticação nos templates.Link para este cabeçalho

O usuário atualmente autenticado e suas permissões são disponibilizadas no contexto do template quando você usa a RequestContext.

UsuáriosLink para este cabeçalho

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 }}:

Django template

{% 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õesLink para este cabeçalho

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:

Django template

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

Django template

{% if perms.foo.add_vote %}

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

Django 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:

Django template

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

Gerenciando usuários no adminLink para este cabeçalho

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áriosLink para este cabeçalho

You should see a link to “Users” in the “Auth” section of the main admin index page. The “Add user” admin page is different than standard admin pages in that it requires you to choose a username and password before allowing you to edit the rest of the user’s fields. Alternatively, on this page, you can choose a username and disable password-based authentication for the user.

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 senhasLink para este cabeçalho

User passwords are not displayed in the admin (nor stored in the database), but the password storage details are displayed. Included in the display of this information is a link to a password change form that allows admins to change or unset user passwords.

Usando o sistema de autenticação DjangoLink para este cabeçalho#

Objetos “User”Link para este cabeçalho#

Criando usuáriosLink para este cabeçalho#

Criando superusuáriosLink para este cabeçalho#

Mudando as senhasLink para este cabeçalho#

Autenticando usuáriosLink para este cabeçalho#

Permissões e AutorizaçãoLink para este cabeçalho#

Permissões padrãoLink para este cabeçalho#

GruposLink para este cabeçalho#

Programaticamente criando permissõesLink para este cabeçalho#

Cache de permissõesLink para este cabeçalho#

Modelos ProxyLink para este cabeçalho#

Authentication in web requestsLink para este cabeçalho#

Como autenticar um usuárioLink para este cabeçalho#

Selecionando o “backend” de autenticaçãoLink para este cabeçalho#

Como finalizar a sessão de um usuárioLink para este cabeçalho#

Limitando o acesso de usuários authenticadosLink para este cabeçalho#

A maneira padrãoLink para este cabeçalho#

O login_required decoratorLink para este cabeçalho#

The LoginRequiredMixin mixinLink para este cabeçalho#

The login_not_required decoratorLink para este cabeçalho#

Limitando o acesso de usuários autenticados que passam no teste.Link para este cabeçalho#

O permission_required decoratorLink para este cabeçalho#

O PermissionRequiredMixin mixinLink para este cabeçalho#

Redirecionando requisições não autorizadas em “views” baseadas em classesLink para este cabeçalho#

Invalidação de Sessão após a Troca de Senha.Link para este cabeçalho#

Views de autenticaçãoLink para este cabeçalho#

Usando as viewsLink para este cabeçalho#

Todas as views de autenticaçãoLink para este cabeçalho#

Funções auxiliaresLink para este cabeçalho#

Formulários embutidosLink para este cabeçalho#

Dados de autenticação nos templates.Link para este cabeçalho#

UsuáriosLink para este cabeçalho#

PermissõesLink para este cabeçalho#

Gerenciando usuários no adminLink para este cabeçalho#

Criando usuáriosLink para este cabeçalho#

Mudando as senhasLink para este cabeçalho#

Usando o sistema de autenticação DjangoLink para este cabeçalho

Objetos “User”Link para este cabeçalho

Criando usuáriosLink para este cabeçalho

Criando superusuáriosLink para este cabeçalho

Mudando as senhasLink para este cabeçalho

Autenticando usuáriosLink para este cabeçalho

Permissões e AutorizaçãoLink para este cabeçalho

Permissões padrãoLink para este cabeçalho

GruposLink para este cabeçalho

Programaticamente criando permissõesLink para este cabeçalho

Cache de permissõesLink para este cabeçalho

Modelos ProxyLink para este cabeçalho

Authentication in web requestsLink para este cabeçalho

Como autenticar um usuárioLink para este cabeçalho

Selecionando o “backend” de autenticaçãoLink para este cabeçalho

Como finalizar a sessão de um usuárioLink para este cabeçalho

Limitando o acesso de usuários authenticadosLink para este cabeçalho

A maneira padrãoLink para este cabeçalho

O `login_required` decoratorLink para este cabeçalho

The `LoginRequiredMixin` mixinLink para este cabeçalho

The `login_not_required` decoratorLink para este cabeçalho

Limitando o acesso de usuários autenticados que passam no teste.Link para este cabeçalho

O `permission_required` decoratorLink para este cabeçalho

O `PermissionRequiredMixin` mixinLink para este cabeçalho

Redirecionando requisições não autorizadas em “views” baseadas em classesLink para este cabeçalho

Invalidação de Sessão após a Troca de Senha.Link para este cabeçalho

Views de autenticaçãoLink para este cabeçalho

Usando as viewsLink para este cabeçalho

Todas as views de autenticaçãoLink para este cabeçalho

Funções auxiliaresLink para este cabeçalho

Formulários embutidosLink para este cabeçalho

Dados de autenticação nos templates.Link para este cabeçalho

UsuáriosLink para este cabeçalho

PermissõesLink para este cabeçalho

Gerenciando usuários no adminLink para este cabeçalho

Criando usuáriosLink para este cabeçalho

Mudando as senhasLink para este cabeçalho