Använda Djangos autentiseringssystem¶

Detta dokument förklarar användningen av Djangos autentiseringssystem i dess standardkonfiguration. Denna konfiguration har utvecklats för att tjäna de vanligaste projektbehoven, hantera ett rimligt brett spektrum av uppgifter och har en noggrann implementering av lösenord och behörigheter. För projekt där autentiseringsbehoven skiljer sig från standardkonfigurationen stöder Django omfattande förlängning och anpassning av autentisering.

Django Authentication tillhandahåller både autentisering och auktorisering tillsammans och kallas i allmänhet autentiseringssystemet, eftersom dessa funktioner är något kopplade.

`User`-objekt¶

User-objekt är kärnan i autentiseringssystemet. De representerar vanligtvis de personer som interagerar med din webbplats och används för att möjliggöra saker som att begränsa åtkomst, registrera användarprofiler, associera innehåll med skapare etc. Endast en klass av användare finns i Djangos autentiseringsramverk, dvs. 'superusers' eller admin 'staff' användare är bara användarobjekt med speciella attribut inställda, inte olika klasser av användarobjekt.

De primära attributen för standardanvändaren är:

Se full API-dokumentation för fullständig referens, dokumentationen som följer är mer uppgiftsorienterad.

Skapa användare¶

Det mest direkta sättet att skapa användare är att använda den inkluderade create_user() hjälpfunktionen:

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

Om du har Django admin installerat kan du också skapa användare interaktivt.

Skapa superanvändare¶

Skapa superanvändare med hjälp av kommandot createsuperuser:

/ 

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

...\> py manage.py createsuperuser --username=joe --email=joe@example.com

Du kommer att bli ombedd att ange ett lösenord. När du har angett ett skapas användaren omedelbart. Om du utelämnar alternativen --username eller --email kommer du att bli tillfrågad om dessa värden.

Byte av lösenord¶

Django lagrar inte råa (klartext) lösenord i användarmodellen, utan endast en hash (se dokumentation av hur lösenord hanteras för fullständiga detaljer). På grund av detta ska du inte försöka manipulera användarens lösenordsattribut direkt. Det är därför som en hjälpfunktion används när en användare skapas.

Om du vill ändra en användares lösenord har du flera alternativ:

manage.py changepassword *username* erbjuder en metod för att ändra en användares lösenord från kommandoraden. Du uppmanas att ändra lösenordet för en viss användare och du måste ange det två gånger. Om båda stämmer överens kommer det nya lösenordet att ändras omedelbart. Om du inte anger någon användare kommer kommandot att försöka ändra lösenordet för den användare vars användarnamn matchar den aktuella systemanvändaren.

Du kan också ändra ett lösenord programmatiskt med set_password():

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

Om du har Django admin installerat kan du också ändra användarens lösenord på autentiseringssystemets adminsidor.

Django tillhandahåller även views och forms som kan användas för att låta användare ändra sina egna lösenord.

Om du ändrar en användares lösenord loggas alla deras sessioner ut. Se Inaktivering av session vid byte av lösenord för mer information.

Autentisering av användare¶

authenticate(request=None, **credentials)[source]¶

aauthenticate(request=None, **credentials)¶

Asynkron version: aauthenticate()

Använd authenticate() för att verifiera en uppsättning autentiseringsuppgifter. Den tar referenser som nyckelordsargument, användarnamn och lösenord för standardfallet, kontrollerar dem mot varje :ref:authentication backend <authentication-backends>`, och returnerar ett :class:`~django.contrib.auth.models.User`-objekt om referensen är giltig för en backend. Om autentiseringsuppgifterna inte är giltiga för någon backend eller om en backend ger upphov till :class:`~django.core.exceptions.PermissionDenied`, returnerar den ``None. Till exempel:

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 är en valfri HttpRequest som skickas till authenticate()-metoden i autentiseringsbackends.

Observera

Detta är ett lågnivåsätt att autentisera en uppsättning referenser; det används till exempel av RemoteUserMiddleware. Om du inte skriver ditt eget autentiseringssystem kommer du förmodligen inte att använda detta. Om du letar efter ett sätt att logga in en användare använder du istället LoginView.

Behörigheter och auktorisering¶

Django levereras med ett inbyggt behörighetssystem. Det ger ett sätt att tilldela behörigheter till specifika användare och grupper av användare.

Den används av Django-adminsidan, men du är välkommen att använda den i din egen kod.

Django-administratörsplatsen använder behörigheter enligt följande:

Åtkomst till visningsobjekt är begränsad till användare med behörigheten ”visa” eller ”ändra” för den typen av objekt.
Tillgång till att visa formuläret ”Lägg till” och lägga till ett objekt är begränsad till användare med behörigheten ”Lägg till” för den typen av objekt.
Åtkomst till att se ändringslistan, se ändringsformuläret och ändra ett objekt är begränsad till användare med behörigheten ”ändra” för den typen av objekt.
Åtkomst till att ta bort ett objekt är begränsad till användare med behörigheten ”ta bort” för den typen av objekt.

Behörigheter kan ställas in inte bara per objekttyp, utan också per specifik objektinstans. Genom att använda has_view_permission(), has_add_permission(), has_change_permission() och has_delete_permission() som tillhandahålls av klassen ModelAdmin är det möjligt att anpassa behörigheter för olika objektinstanser av samma typ.

User-objekt har två many-to-many-fält: groups och user_permissions. User-objekt kan komma åt sina relaterade objekt på samma sätt som alla andra Django model:

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

Standardbehörighet¶

När django.contrib.auth är listad i din INSTALLED_APPS-inställning, kommer den att se till att fyra standardbehörigheter - lägg till, ändra, ta bort och visa - skapas för varje Django-modell som definieras i en av dina installerade applikationer.

Dessa behörigheter skapas när du kör manage.py migrate; första gången du kör migrate efter att ha lagt till django.contrib.auth i INSTALLED_APPS, skapas standardbehörigheterna för alla tidigare installerade modeller, samt för alla nya modeller som installeras vid den tidpunkten. Efteråt skapas standardbehörigheter för nya modeller varje gång du kör manage.py migrate (funktionen som skapar behörigheter är kopplad till signalen post_migrate).

Anta att du har en applikation med en app_label foo och en modell som heter Bar, för att testa för grundläggande behörigheter bör du använda:

add: user.has_perm('foo.add_bar')
ändring: user.has_perm('foo.change_bar')
radera: user.has_perm('foo.delete_bar')
vy: user.has_perm('foo.view_bar')

Modellen Permission är sällan direkt åtkomlig.

Grupper¶

django.contrib.auth.models.Group modeller är ett generiskt sätt att kategorisera användare så att du kan tillämpa behörigheter, eller någon annan etikett, för dessa användare. En användare kan tillhöra ett obegränsat antal grupper.

En användare i en grupp har automatiskt de behörigheter som gruppen har tilldelats. Om till exempel gruppen Site editors har behörigheten can_edit_home_page, kommer alla användare i den gruppen att ha den behörigheten.

Utöver behörigheter är grupper ett bekvämt sätt att kategorisera användare för att ge dem en viss etikett eller utökad funktionalitet. Du kan till exempel skapa en grupp med namnet ”Special users” och skriva kod som ger dem tillgång till en del av webbplatsen som endast är tillgänglig för medlemmar eller skicka e-postmeddelanden som endast är tillgängliga för medlemmar.

Skapa behörigheter programmatiskt¶

Medan :ref:custom permissions <custom-permissions> kan definieras i en modells Meta-klass, kan du också skapa behörigheter direkt. Du kan till exempel skapa behörigheten can_publish för en BlogPost-modell i myapp:

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

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

Behörigheten kan sedan tilldelas en User via dess attribut user_permissions eller till en Group via dess attribut permissions.

Proxy-modeller behöver sin egen innehållstyp

Om du vill skapa behörigheter för en proxymodell, skicka for_concrete_model=False till ContentTypeManager.get_for_model() för att få rätt ContentType:

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

Cachelagring av behörigheter¶

ModelBackend cachelagrar behörigheter på användarobjektet efter första gången de behöver hämtas för en behörighetskontroll. Detta är vanligtvis bra för begäran-svar-cykeln eftersom behörigheter vanligtvis inte kontrolleras omedelbart efter att de har lagts till (i administratören, till exempel). Om du lägger till behörigheter och kontrollerar dem omedelbart efteråt, till exempel i ett test eller en vy, är den enklaste lösningen att hämta användaren på nytt från databasen. Till exempel:

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

    ...

Proxy-modeller¶

Proxymodeller fungerar på exakt samma sätt som konkreta modeller. Behörigheter skapas med hjälp av proxymodellens egen innehållstyp. Proxymodeller ärver inte behörigheterna för den konkreta modell som de är subklass till:

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


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

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

Autentisering i webbförfrågningar¶

Django använder sessions och middleware för att koppla autentiseringssystemet till request-objekt.

Dessa tillhandahåller ett request.user-attribut och en request.auser async-metod på varje begäran som representerar den aktuella användaren. Om den aktuella användaren inte har loggat in kommer detta attribut att sättas till en instans av AnonymousUser, annars kommer det att vara en instans av User.

Du kan skilja dem åt med is_authenticated, så här:

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

Eller i en asynkron vy:

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

Så här loggar du in en användare¶

Om du har en autentiserad användare som du vill koppla till den aktuella sessionen - detta görs med en login()-funktion.

login(request, user, backend=None)[source]¶

alogin(request, user, backend=None)¶

Asynkron version: alogin()`

För att logga in en användare från en vy, använd login(). Den tar ett HttpRequest-objekt och ett User-objekt. login() sparar användarens ID i sessionen med hjälp av Djangos sessionsramverk.

Observera att alla uppgifter som anges under den anonyma sessionen sparas i sessionen efter att en användare loggat in.

Detta exempel visar hur du kan använda både authenticate() och login():

from django.contrib.auth import authenticate, login


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

Välja backend för autentisering¶

När en användare loggar in sparas användarens ID och den backend som användes för autentisering i användarens session. Detta gör att samma autentiseringsbackend kan hämta användarens uppgifter vid en framtida begäran. Den autentiseringsbackend som ska sparas i sessionen väljs enligt följande:

Använd värdet för det valfria argumentet backend, om det anges.
Använd värdet på attributet user.backend, om det finns. Detta gör det möjligt att para ihop authenticate() och login(): authenticate() sätter attributet user.backend på det användarobjekt som returneras.
Använd backend i AUTHENTICATION_BACKENDS, om det bara finns en.
I annat fall, skapa ett undantag.

I fall 1 och 2 ska värdet för argumentet backend eller attributet user.backend vara en sträng med prickad importsökväg (som den som finns i AUTHENTICATION_BACKENDS), inte den faktiska backendklassen.

Så här loggar du ut en användare¶

logout(request)[source]¶

alogout(request)¶

Asynkron version: alogout()

För att logga ut en användare som har loggat in via django.contrib.auth.login(), använd django.contrib.auth.logout() i din vy. Den tar ett HttpRequest-objekt och har inget returvärde. Exempel:

from django.contrib.auth import logout


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

Observera att logout() inte ger några felmeddelanden om användaren inte var inloggad.

När du anropar logout() rensas sessionsdata för den aktuella begäran helt och hållet. Alla befintliga data tas bort. Detta för att förhindra att en annan person använder samma webbläsare för att logga in och få tillgång till den tidigare användarens sessionsdata. Om du vill lägga in något i sessionen som kommer att vara tillgängligt för användaren omedelbart efter utloggning, gör det efter anropet django.contrib.auth.logout().

Begränsning av åtkomst till inloggade användare¶

Det råa sättet¶

Det enkla sättet att begränsa åtkomst till sidor är att kontrollera request.user.is_authenticated och antingen omdirigera till en inloggningssida:

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}")
    # ...

…eller visa ett felmeddelande:

from django.shortcuts import render


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

Dekoratorn `login_required` (inloggning krävs)¶

login_required(redirect_field_name='next', login_url=None)[source]¶

Som en genväg kan du använda den praktiska login_required() decorator:

from django.contrib.auth.decorators import login_required


@login_required
def my_view(request): ...

login_required() gör följande:

Om användaren inte är inloggad, omdirigera till settings.LOGIN_URL och ange den aktuella absoluta sökvägen i frågesträngen. Exempel: /accounts/login/?next=/polls/3/.
Om användaren är inloggad körs vyn normalt. Det står vykoden fritt att anta att användaren är inloggad.

Som standard lagras den sökväg som användaren ska omdirigeras till efter framgångsrik autentisering i en frågesträngsparameter som heter "next". Om du föredrar att använda ett annat namn för denna parameter, login_required() tar en valfri redirect_field_name parameter:

from django.contrib.auth.decorators import login_required


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

Observera att om du anger ett värde för redirect_field_name kommer du troligen att behöva anpassa din inloggningsmall också, eftersom mallens kontextvariabel som lagrar omdirigeringssökvägen kommer att använda värdet för redirect_field_name som nyckel i stället för "next" (standard).

login_required() tar också en valfri login_url parameter. Exempel:

from django.contrib.auth.decorators import login_required


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

Observera att om du inte anger parametern login_url måste du se till att settings.LOGIN_URL och din inloggningsvy är korrekt associerade. Använd till exempel standardinställningarna och lägg till följande rader i din URLconf:

from django.contrib.auth import views as auth_views

path("accounts/login/", auth_views.LoginView.as_view()),

Inställningen settings.LOGIN_URL accepterar även namn på vyfunktioner och named URL patterns. Detta gör att du fritt kan ändra din inloggningsvy i din URLconf utan att behöva uppdatera inställningen.

Observera

Dekoratorn login_required kontrollerar INTE flaggan is_active på en användare, men standardinställningen AUTHENTICATION_BACKENDS avvisar inaktiva användare.

Se även

Om du skriver anpassade vyer för Djangos admin (eller behöver samma behörighetskontroll som de inbyggda vyerna använder), kan du tycka att django.contrib.admin.views.decorators.staff_member_required() dekoratorn är ett användbart alternativ till login_required().

Changed in Django 5.1:

Stöd för inkapsling av asynkrona vyfunktioner har lagts till.

Mixin `LoginRequiredMixin` mixin¶

När du använder klassbaserade vyer kan du uppnå samma beteende som med login_required genom att använda LoginRequiredMixin. Denna mixin bör vara längst till vänster i arvslistan.

class LoginRequiredMixin[source]¶

Om en vy använder denna mixin kommer alla förfrågningar från icke-autentiserade användare att omdirigeras till inloggningssidan eller visa ett HTTP 403 Forbidden-fel, beroende på raise_exception-parametern.

Du kan ställa in någon av parametrarna i AccessMixin för att anpassa hanteringen av obehöriga användare:

from django.contrib.auth.mixins import LoginRequiredMixin


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

Observera

Precis som dekoratorn login_required kontrollerar denna mixin INTE flaggan is_active på en användare, men standardinställningen AUTHENTICATION_BACKENDS avvisar inaktiva användare.

Dekoratorn `login_not_required`¶

New in Django 5.1.

När LoginRequiredMiddleware är installerad kräver alla vyer autentisering som standard. Vissa vyer, t.ex. inloggningsvyn, kan behöva inaktivera detta beteende.

login_not_required()[source]¶: Tillåter oautentiserade förfrågningar till denna vy när LoginRequiredMiddleware är installerad.

Begränsa åtkomsten till inloggade användare som klarar ett test¶

Om du vill begränsa åtkomsten baserat på vissa behörigheter eller något annat test gör du i princip samma sak som beskrivs i föregående avsnitt.

Du kan köra ditt test på request.user i vyn direkt. Till exempel kontrollerar den här vyn att användaren har en e-postadress i den önskade domänen och om inte, omdirigeras till inloggningssidan:

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')[source]¶

Som en genväg kan du använda den praktiska dekoratorn user_passes_test som utför en omdirigering när den anropsbara returnerar 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): ...

user_passes_test() tar ett obligatoriskt argument: en anropbar som tar ett User-objekt och returnerar True om användaren får visa sidan. Observera att user_passes_test() inte automatiskt kontrollerar att User inte är anonym.

user_passes_test() tar två valfria argument:

login_url: Låter dig ange den URL som användare som inte klarar testet kommer att omdirigeras till. Det kan vara en inloggningssida och standardvärdet är settings.LOGIN_URL om du inte anger någon.
omdirigering_fältnamn: Samma som för login_required(). Om du ställer in den på None tas den bort från webbadressen, vilket du kanske vill göra om du omdirigerar användare som inte klarar testet till en icke-inloggningssida där det inte finns någon ”nästa sida”.

Till exempel:

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

Changed in Django 5.1:

Stöd för inkapsling av asynkrona vyfunktioner och användning av asynkrona testkallelser har lagts till.

class UserPassesTestMixin[source]¶

När du använder klassbaserade vyer kan du använda UserPassesTestMixin för att göra detta.

test_func()[source]¶

Du måste åsidosätta metoden test_func() i klassen för att tillhandahålla det test som utförs. Dessutom kan du ställa in någon av parametrarna i AccessMixin för att anpassa hanteringen av obehöriga användare:

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()[source]¶: Du kan också åsidosätta metoden get_test_func() för att mixin ska använda en funktion med ett annat namn för sina kontroller (i stället för test_func()).

Stapling av UserPassesTestMixin

På grund av det sätt som UserPassesTestMixin implementeras kan du inte stapla dem i din arvslista. Följande fungerar INTE:

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

Om TestMixin1 skulle anropa super() och ta hänsyn till det resultatet, skulle TestMixin1 inte fungera fristående längre.

Dekoratorn `permission_required` (tillstånd krävs)¶

permission_required(perm, login_url=None, raise_exception=False)[source]¶

Det är en relativt vanlig uppgift att kontrollera om en användare har en viss behörighet. Av den anledningen tillhandahåller Django en genväg för det fallet: permission_required() decorator:

from django.contrib.auth.decorators import permission_required


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

Precis som metoden has_perm(), har namn på behörigheter formen "<app label>.<permission codename>" (t.ex. polls.add_choice för en behörighet på en modell i applikationen polls).

Dekoratorn kan också ta en iterabel av behörigheter, i vilket fall användaren måste ha alla behörigheter för att få tillgång till vyn.

Observera att permission_required() också tar en valfri login_url parameter:

from django.contrib.auth.decorators import permission_required


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

Precis som i login_required()-dekoratorn är login_url standardvärdet för settings.LOGIN_URL.

Om parametern raise_exception anges, kommer dekoratorn att höja PermissionDenied och uppmana :ref:` 403 (HTTP Forbidden)-vyn<http_forbidden_view>` istället för att omdirigera till inloggningssidan.

Om du vill använda raise_exception men också ge dina användare en chans att logga in först, kan du lägga till login_required() decorator:

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


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

Detta undviker också en omdirigeringsslinga när LoginView’s redirect_authenticated_user=True och den inloggade användaren inte har alla nödvändiga behörigheter.

Changed in Django 5.1:

Stöd för inkapsling av asynkrona vyfunktioner har lagts till.

Mixin `PermissionRequiredMixin` mixin¶

För att tillämpa behörighetskontroller på klassbaserade vyer kan du använda PermissionRequiredMixin:

class PermissionRequiredMixin[source]¶

Denna mixin, precis som dekoratorn permission_required, kontrollerar om användaren som öppnar en vy har alla givna behörigheter. Du bör ange behörigheten (eller en iterabel av behörigheter) med hjälp av parametern 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"]

Du kan ställa in någon av parametrarna i AccessMixin för att anpassa hanteringen av obehöriga användare.

Du kan också åsidosätta dessa metoder:

get_permission_required()[source]¶: Returnerar en iterabel med namn på behörigheter som används av mixinen. Standard är attributet permission_required, konverterat till en tupel om det behövs.

has_permission()[source]¶: Returnerar en boolean som anger om den aktuella användaren har behörighet att köra den dekorerade vyn. Som standard returnerar detta resultatet av att anropa has_perms() med listan över behörigheter som returneras av get_permission_required().

Omdirigering av obehöriga förfrågningar i klassbaserade vyer¶

För att underlätta hanteringen av åtkomstbegränsningar i klassbaserade vyer kan AccessMixin användas för att konfigurera beteendet för en vy när åtkomst nekas. Autentiserade användare nekas åtkomst med ett HTTP 403 Forbidden-svar. Anonyma användare omdirigeras till inloggningssidan eller visas ett HTTP 403 Forbidden-svar, beroende på attributet raise_exception.

class AccessMixin[source]¶

login_url¶: Standardreturvärde för get_login_url(). Standardvärdet är None i vilket fall get_login_url() återgår till settings.LOGIN_URL.

permission_denied_message¶: Standardavkastningsvärde för get_permission_denied_message(). Standardvärdet är en tom sträng.

redirect_field_name¶: Standardreturvärde för get_redirect_field_name(). Standardvärdet är "next".

raise_exception¶: Om detta attribut är inställt på True, kommer ett PermissionDenied undantag att uppstå när villkoren inte är uppfyllda. När False (standard) omdirigeras anonyma användare till inloggningssidan.

get_login_url()[source]¶: Returnerar URL:en som användare som inte klarar testet kommer att omdirigeras till. Returnerar login_url om den är inställd, eller settings.LOGIN_URL annars.

get_permission_denied_message()[source]¶: När raise_exception är True kan denna metod användas för att styra det felmeddelande som skickas till felhanteraren för visning till användaren. Returnerar attributet permission_denied_message som standard.

get_redirect_field_name()[source]¶: Returnerar namnet på den frågeparameter som kommer att innehålla den URL som användaren ska omdirigeras till efter en lyckad inloggning. Om du anger None kommer ingen frågeparameter att läggas till. Returnerar attributet redirect_field_name som standard.

handle_no_permission()[source]¶: Beroende på värdet av raise_exception, ger metoden antingen upphov till ett PermissionDenied` undantag eller omdirigerar användaren till login_url, eventuellt inklusive redirect_field_name om det är inställt.

Inaktivering av session vid byte av lösenord¶

Om din AUTH_USER_MODEL ärver från AbstractBaseUser eller implementerar sin egen get_session_auth_hash()-metod, kommer autentiserade sessioner att innehålla den hash som returneras av denna funktion. I fallet AbstractBaseUser är detta en HMAC av lösenordsfältet. Django verifierar att hashen i sessionen för varje begäran matchar den som beräknas under begäran. Detta gör det möjligt för en användare att logga ut alla sina sessioner genom att ändra sitt lösenord.

Standardvyerna för lösenordsändring som ingår i Django, PasswordChangeView och vyn user_change_password i django.contrib.auth admin, uppdaterar sessionen med den nya lösenordshashen så att en användare som ändrar sitt eget lösenord inte loggar ut sig själv. Om du har en anpassad vy för lösenordsändring och vill ha ett liknande beteende, använd funktionen update_session_auth_hash().

update_session_auth_hash(request, user)[source]¶

aupdate_session_auth_hash(request, user)¶

Asynkron version: aupdate_session_auth_hash()

Denna funktion tar den aktuella begäran och det uppdaterade användarobjektet från vilket den nya sessionshashningen kommer att härledas och uppdaterar sessionshashningen på lämpligt sätt. Den roterar också sessionsnyckeln så att en stulen sessionskaka ogiltigförklaras.

Exempel på användning:

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

Observera

Eftersom get_session_auth_hash() baseras på SECRET_KEY, måste hemliga nyckelvärden roteras för att undvika att befintliga sessioner ogiltigförklaras när du uppdaterar din webbplats för att använda en ny hemlighet. Se SECRET_KEY_FALLBACKS för mer information.

Autentiseringsvyer¶

Django tillhandahåller flera vyer som du kan använda för att hantera inloggning, utloggning och lösenordshantering. Dessa använder stock auth forms men du kan också skicka in dina egna formulär.

Django tillhandahåller ingen standardmall för autentiseringsvyerna. Du bör skapa dina egna mallar för de vyer du vill använda. Mallkontexten är dokumenterad i varje vy, se Alla autentiseringsvyer.

Använda vyerna¶

Det finns olika metoder för att implementera dessa vyer i ditt projekt. Det enklaste sättet är att inkludera den tillhandahållna URLconf i django.contrib.auth.urls i din egen URLconf, till exempel:

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

Detta kommer att omfatta följande URL-mönster:

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']

Vyerna ger ett URL-namn för enklare referens. Se URL-dokumentationen för information om hur du använder namngivna URL-mönster.

Om du vill ha mer kontroll över dina webbadresser kan du referera till en specifik vy i din URLconf:

from django.contrib.auth import views as auth_views

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

Vyerna har valfria argument som du kan använda för att ändra vyns beteende. Om du t.ex. vill ändra mallnamnet som en vy använder kan du ange argumentet template_name. Ett sätt att göra detta är att ange nyckelordsargument i URLconf, dessa kommer att vidarebefordras till vyn. Till exempel:

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

Alla vyer är klassbaserade, vilket gör att du enkelt kan anpassa dem genom subklassning.

Alla autentiseringsvyer¶

Detta är en lista med alla vyer som django.contrib.auth tillhandahåller. För implementationsdetaljer se Använda vyerna.

class LoginView[source]¶

Namn på webbadress: login

Se URL-dokumentationen för mer information om hur du använder namngivna URL-mönster.

Metoder och egenskaper

template_name¶: Namnet på en mall som ska visas för den vy som används för att logga in användaren. Standardvärdet är registration/login.html.

next_page¶: Den URL som ska omdirigeras till efter inloggning. Standardvärde är LOGIN_REDIRECT_URL.

redirect_field_name¶: Namnet på ett GET-fält som innehåller den URL som ska omdirigeras till efter inloggning. Standard är next. Åsidosätter get_default_redirect_url() URL om den angivna GET parametern skickas.

authentication_form¶: En anropsbar (vanligtvis en formulärklass) som ska användas för autentisering. Standardinställning är AuthenticationForm.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

redirect_authenticated_user¶: Ett boolean som styr om autentiserade användare som öppnar inloggningssidan ska omdirigeras som om de precis hade loggat in. Standardvärdet är False.

Varning

Om du aktiverar redirect_authenticated_user kommer andra webbplatser att kunna avgöra om deras besökare är autentiserade på din webbplats genom att begära omdirigeringsadresser till bildfiler på din webbplats. För att undvika detta ”social media fingerprinting” informationsläckage, hosta alla bilder och din favicon på en separat domän.

Om du aktiverar redirect_authenticated_user kan det också resultera i en omdirigeringsloop när du använder permission_required()-dekoratorn om inte parametern raise_exception används.

success_url_allowed_hosts¶: En uppsättning av värdar, utöver request.get_host(), som är säkra för omdirigering efter inloggning. Standardvärdet är en tom set.

get_default_redirect_url()[source]¶: Returnerar den URL som ska omdirigeras till efter inloggning. Standardimplementeringen löser och returnerar next_page om den är inställd, eller LOGIN_REDIRECT_URL annars.

Här är vad LoginView gör:

Om den anropas via GET visar den ett inloggningsformulär som POSTAS till samma URL. Mer om detta om en liten stund.
Om den anropas via POST med inloggningsuppgifter från användaren försöker den logga in användaren. Om inloggningen lyckas omdirigeras vyn till den URL som anges i next. Om next inte anges, omdirigeras den till settings.LOGIN_REDIRECT_URL (som standard till /accounts/profile/). Om inloggningen inte lyckas visas inloggningsformuläret på nytt.

Det är ditt ansvar att tillhandahålla html för inloggningsmallen, som heter registration/login.html som standard. Den här mallen får fyra mallkontextvariabler:

form: Ett Form-objekt som representerar AuthenticationForm.
nästa: Den URL som ska omdirigeras till efter en lyckad inloggning. Den kan också innehålla en frågesträng.
site: Den aktuella Site, enligt inställningen SITE_ID. Om du inte har installerat webbplatsramverket kommer detta att ställas in till en instans av RequestSite, som härleder webbplatsnamnet och domänen från den aktuella HttpRequest.
site_name: Ett alias för site.name. Om du inte har installerat site-ramverket kommer detta att ställas in till värdet av request.META['SERVER_NAME']. För mer information om webbplatser, se Ramverket för ”webbplatser”.

Om du föredrar att inte anropa mallen registration/login.html kan du skicka parametern template_name via de extra argumenten till metoden as_view i din URLconf. Till exempel skulle denna URLconf-rad använda myapp/login.html istället:

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

Du kan också ange namnet på fältet GET som innehåller den URL som ska omdirigeras till efter inloggning med hjälp av redirect_field_name. Som standard kallas fältet next.

Här är ett exempel på en mall för registration/login.html som du kan använda som utgångspunkt. Det förutsätter att du har en base.html-mall som definierar ett content-block:

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

Om du har anpassat autentiseringen (se Customizing Authentication) kan du använda ett anpassat autentiseringsformulär genom att ange attributet authentication_form. Detta formulär måste acceptera ett argument med nyckelordet request i sin metod __init__() och tillhandahålla en metod get_user() som returnerar det autentiserade användarobjektet (denna metod anropas endast efter en lyckad formulärvalidering).

class LogoutView[source]¶

Loggar ut en användare på POST-förfrågningar.

Namn på webbadress: logout

Attribut:

next_page¶: Den URL som ska omdirigeras till efter utloggning. Standardvärde är LOGOUT_REDIRECT_URL.

template_name¶: Det fullständiga namnet på en mall som ska visas efter att användaren har loggat ut. Standardvärdet är registration/logged_out.html.

redirect_field_name¶: Namnet på ett GET-fält som innehåller den URL som ska omdirigeras till efter utloggning. Standard är 'next'. Åsidosätter next_page URL om den angivna GET parametern skickas.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

success_url_allowed_hosts¶: En uppsättning av värdar, utöver request.get_host(), som är säkra för omdirigering efter utloggning. Standardvärdet är en tom set.

Template context:

title: Strängen ”Logged out”, lokaliserad.
site: Den aktuella Site, enligt inställningen SITE_ID. Om du inte har installerat webbplatsramverket kommer detta att ställas in till en instans av RequestSite, som härleder webbplatsnamnet och domänen från den aktuella HttpRequest.
site_name: Ett alias för site.name. Om du inte har installerat site-ramverket kommer detta att ställas in till värdet av request.META['SERVER_NAME']. För mer information om webbplatser, se Ramverket för ”webbplatser”.

logout_then_login(request, login_url=None)[source]¶

Loggar ut en användare på POST-förfrågningar och omdirigerar sedan till inloggningssidan.

URL-namn: Ingen standard-URL angiven

**Valfria argument: **

login_url: URL-adressen till inloggningssidan som du ska omdirigeras till. Standardvärdet är settings.LOGIN_URL om det inte anges.

class PasswordChangeView[source]¶

Namn på webbadress: password_change

Tillåter en användare att ändra sitt lösenord.

Attribut:

template_name¶: Det fullständiga namnet på en mall som ska användas för att visa formuläret för lösenordsändring. Standardvärdet är registration/password_change_form.html om det inte anges.

success_url¶: Den URL som ska omdirigeras till efter en lyckad lösenordsändring. Standard är 'password_change_done.

form_class¶: Ett anpassat formulär för ”byte av lösenord” som måste acceptera ett argument i form av nyckelordet user. Formuläret är ansvarigt för att faktiskt ändra användarens lösenord. Standardinställning är PasswordChangeForm.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

Template context:

formulär: Formuläret för lösenordsändring (se form_class ovan).

class PasswordChangeDoneView[source]¶

Namn på webbadress: password_change_done

Den sida som visas efter att en användare har bytt lösenord.

Attribut:

template_name¶: Det fullständiga namnet på en mall som ska användas. Standardvärdet är registration/password_change_done.html om det inte anges.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

class PasswordResetView[source]¶

Namn på webbadress: password_reset

Gör det möjligt för en användare att återställa sitt lösenord genom att generera en engångslänk som kan användas för att återställa lösenordet och skicka länken till användarens registrerade e-postadress.

Den här vyn skickar ett e-postmeddelande om följande villkor är uppfyllda:

Den angivna e-postadressen finns i systemet.
Den begärda användaren är aktiv (User.is_active är True).
Den begärda användaren har ett användbart lösenord. Användare som flaggas med ett oanvändbart lösenord (se set_unusable_password()) får inte begära en återställning av lösenordet för att förhindra missbruk vid användning av en extern autentiseringskälla som LDAP.

Om något av dessa villkor inte är uppfyllt skickas inget e-postmeddelande, men användaren får inte heller något felmeddelande. Detta förhindrar att information läcker ut till potentiella angripare. Om du vill tillhandahålla ett felmeddelande i det här fallet kan du underordna dig PasswordResetForm och använda attributet form_class.

Observera

Tänk på att det tar extra tid att skicka ett e-postmeddelande och att du därför kan utsättas för en tidsattack med uppräkning av e-postadresser på grund av skillnaden mellan varaktigheten för en återställningsbegäran för en befintlig e-postadress och varaktigheten för en återställningsbegäran för en icke-existerande e-postadress. För att minska omkostnaderna kan du använda ett tredjepartspaket som gör det möjligt att skicka e-postmeddelanden asynkront, t.ex. django-mailer.

Attribut:

template_name¶: Det fullständiga namnet på en mall som ska användas för att visa formuläret för återställning av lösenord. Standardvärdet är registration/password_reset_form.html om det inte anges.

form_class¶: Formulär som kommer att användas för att få e-postadressen till den användare som lösenordet ska återställas för. Standardinställning är PasswordResetForm.

email_template_name¶: Det fullständiga namnet på en mall som ska användas för att generera e-postmeddelandet med länken för återställning av lösenord. Standardvärdet är registration/password_reset_email.html om det inte anges.

subject_template_name¶: Det fullständiga namnet på en mall som ska användas för ämnet i e-postmeddelandet med länken för återställning av lösenord. Standardvärdet är registration/password_reset_subject.txt om det inte anges.

token_generator¶: Instans av klassen för att kontrollera engångslänken. Detta kommer som standard att vara default_token_generator, det är en instans av django.contrib.auth.tokens.PasswordResetTokenGenerator.

success_url¶: Den URL som ska omdirigeras till efter en lyckad begäran om återställning av lösenord. Standardvärdet är ``’password_reset_done’’.

from_email¶: En giltig e-postadress. Som standard använder Django :inställningen:`DEFAULT_FROM_EMAIL`.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

html_email_template_name¶: Det fullständiga namnet på en mall som ska användas för att generera ett text/html flerdelat e-postmeddelande med länken för återställning av lösenord. Som standard skickas inte HTML-e-post.

extra_email_context¶: En ordbok med kontextdata som kommer att finnas tillgänglig i e-postmallen. Den kan användas för att åsidosätta standardvärden för mallkontext som anges nedan, t.ex. domain.

Template context:

formulär: Formuläret (se form_class ovan) för återställning av användarens lösenord.

**E-postmallens sammanhang: **

email: Ett alias för user.email
user: Den aktuella User, enligt formulärfältet email. Endast aktiva användare kan återställa sina lösenord (User.is_active is True).
site_name: Ett alias för site.name. Om du inte har installerat site-ramverket kommer detta att ställas in till värdet av request.META['SERVER_NAME']. För mer information om webbplatser, se Ramverket för ”webbplatser”.
domän: Ett alias för site.domain. Om du inte har installerat site-ramverket kommer detta att sättas till värdet av request.get_host().
protokoll: http eller https
uid: Användarens primärnyckel kodad i bas 64.
token: Token för att kontrollera att återställningslänken är giltig.

Exempel på registration/password_reset_email.html (mall för e-postens brödtext):

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

Samma mallkontext används för ämnesmallen. Ämnet måste vara en vanlig textsträng på en rad.

class PasswordResetDoneView[source]¶

Namn på webbadress: password_reset_done

Den sida som visas efter att en användare har fått en länk för att återställa sitt lösenord via e-post. Denna vy anropas som standard om PasswordResetView inte har en explicit uccess_url URL inställd.

Observera

Om den angivna e-postadressen inte finns i systemet, användaren är inaktiv eller har ett oanvändbart lösenord, kommer användaren fortfarande att omdirigeras till den här vyn men inget e-postmeddelande kommer att skickas.

Attribut:

template_name¶: Det fullständiga namnet på en mall som ska användas. Standardvärdet är registration/password_reset_done.html om det inte anges.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

class PasswordResetConfirmView[source]¶

Namn på webbadress: password_reset_confirm

Visar ett formulär för att ange ett nytt lösenord.

**Nyckelordsargument från webbadressen: **

uidb64: Användarens id kodat i bas 64.
token: Token för att kontrollera att lösenordet är giltigt.

Attribut:

template_name¶: Det fullständiga namnet på en mall som ska visa vyn för bekräftelse av lösenord. Standardvärdet är registration/password_reset_confirm.html.

token_generator¶: Instans av klassen för att kontrollera lösenordet. Detta kommer som standard att vara default_token_generator, det är en instans av django.contrib.auth.tokens.PasswordResetTokenGenerator.

post_reset_login¶: En boolean som anger om användaren ska autentiseras automatiskt efter en lyckad återställning av lösenordet. Standardvärdet är False.

post_reset_login_backend¶: En prickad sökväg till den autentiseringsbackend som ska användas när en användare autentiseras om post_reset_login är True. Krävs endast om du har flera AUTHENTICATION_BACKENDS konfigurerade. Standardvärdet är None.

form_class¶: Formulär som kommer att användas för att ställa in lösenordet. Standard är SetPasswordForm.

success_url¶: URL att omdirigera efter att lösenordsåterställningen är klar. Standardvärdet är 'password_reset_complete'.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

reset_url_token¶: Tokenparameter som visas som en komponent i URL:er för återställning av lösenord. Standardvärdet är ”set-password”.

Template context:

formulär: Formuläret (se form_class ovan) för att ange den nya användarens lösenord.
validlink: Boolean, True om länken (kombination av uidb64 och token) är giltig eller oanvänd ännu.

class PasswordResetCompleteView[source]¶

Namn på webbadress: password_reset_complete

Visar en vy som informerar användaren om att lösenordet har ändrats.

Attribut:

template_name¶: Det fullständiga namnet på en mall för att visa vyn. Standardvärdet är registration/password_reset_complete.html.

extra_context¶: En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.

Hjälpfunktioner¶

redirect_to_login(next, login_url=None, redirect_field_name='next')[source]¶

Omdirigerar till inloggningssidan och sedan tillbaka till en annan URL efter en lyckad inloggning.

**Nödvändiga argument: **

nästa: Den URL som ska omdirigeras till efter en lyckad inloggning.

**Valfria argument: **

login_url: URL-adressen till inloggningssidan som du ska omdirigeras till. Standardvärdet är settings.LOGIN_URL om det inte anges.
namn på fältet redirect_field_name: Namnet på ett GET-fält som innehåller den URL som ska omdirigeras till efter inloggning. Åsidosätter next om den angivna GET-parametern skickas.

Inbyggda formulär¶

Om du inte vill använda de inbyggda vyerna, men vill ha bekvämligheten med att inte behöva skriva formulär för den här funktionaliteten, tillhandahåller autentiseringssystemet flera inbyggda formulär som finns i django.contrib.auth.forms:

Observera

De inbyggda autentiseringsformulären gör vissa antaganden om den användarmodell som de arbetar med. Om du använder en :ref:``anpassad användarmodell <auth-custom-user>` kan det vara nödvändigt att definiera egna formulär för autentiseringssystemet. Mer information finns i dokumentationen om använda de inbyggda autentiseringsformulären med anpassade användarmodeller.

class AdminPasswordChangeForm[source]¶

Ett formulär som används i admin-gränssnittet för att ändra en användares lösenord, inklusive möjligheten att ange ett unusable password, som blockerar användaren från att logga in med lösenordsbaserad autentisering.

Tar användaren som det första positionella argumentet.

Changed in Django 5.1:

Alternativ för att inaktivera (eller återaktivera) lösenordsbaserad autentisering har lagts till.

class AdminUserCreationForm[source]¶

New in Django 5.1.1.

Ett formulär som används i admin-gränssnittet för att skapa en ny användare. Ärver från UserCreationForm.

Den innehåller ett extra fält usable_password som är aktiverat som standard. Om usable_password är aktiverat verifierar den att password1 och password2 inte är tomma och matchar, validerar lösenordet med validate_password(), och ställer in användarens lösenord med set_password(). Om usable_password är inaktiverat görs ingen lösenordsvalidering och lösenordsbaserad autentisering inaktiveras för användaren genom att anropa set_unusable_password().

class AuthenticationForm[source]¶

Ett formulär för att logga in en användare.

Tar request som sitt första positionella argument, som lagras i formulärinstansen för att användas av underklasser.

confirm_login_allowed(user)[source]¶

Som standard avvisar AuthenticationForm användare vars flagga is_active är inställd på False. Du kan åsidosätta detta beteende med en anpassad policy för att avgöra vilka användare som kan logga in. Gör detta med ett anpassat formulär som underklassar AuthenticationForm och åsidosätter metoden confirm_login_allowed(). Denna metod bör ge upphov till ett ValidationError om den angivna användaren inte kan logga in.

Till exempel, för att tillåta alla användare att logga in oavsett ”aktiv” status:

from django.contrib.auth.forms import AuthenticationForm


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

(I det här fallet måste du också använda en autentiseringsbackend som tillåter inaktiva användare, till exempel AllowAllUsersModelBackend)

Eller för att bara tillåta vissa aktiva användare att logga in:

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 BaseUserCreationForm[source]¶

En ModelForm för att skapa en ny användare. Detta är den rekommenderade basklassen om du behöver anpassa formuläret för att skapa en användare.

Den har tre fält: username (från användarmodellen), password1 och password2. Den kontrollerar att password1 och password2 matchar, validerar lösenordet med validate_password(), och ställer in användarens lösenord med set_password().

class PasswordChangeForm[source]¶: Ett formulär för att tillåta en användare att ändra sitt lösenord.

class PasswordResetForm[source]¶

Ett formulär för att generera och e-posta en engångslänk för att återställa en användares lösenord.

send_mail(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)[source]¶

Använder argumenten för att skicka ett EmailMultiAlternatives. Kan åsidosättas för att anpassa hur e-postmeddelandet skickas till användaren. Om du väljer att åsidosätta den här metoden bör du tänka på att hantera eventuella undantag som uppstår om e-postmeddelandet inte skickas.

Parametrar:

subject_template_name – mallen för ämnet.
email_template_name – mallen för e-postmeddelandets brödtext.
context – kontext som skickas till subject_template, email_template och html_email_template (om det inte är None).
from_email – avsändarens e-postadress.
to_email – e-postadressen till den som begär utdraget.
html_email_template_name – mallen för HTML-texten; standardvärdet är None, i vilket fall ett e-postmeddelande med ren text skickas.

Som standard fyller save() i context med samma variabler som PasswordResetView skickar till sin e-postkontext.

class SetPasswordForm[source]¶: Ett formulär som låter en användare ändra sitt lösenord utan att ange det gamla lösenordet.

class UserChangeForm[source]¶: Ett formulär som används i administratörsgränssnittet för att ändra en användares information och behörigheter.

class UserCreationForm[source]¶: Ärver från BaseUserCreationForm. För att förhindra förväxling med liknande användarnamn tillåter formuläret inte användarnamn som skiljer sig åt endast i bokstäver.

Autentiseringsdata i mallar¶

Den för närvarande inloggade användaren och deras behörigheter görs tillgängliga i template context när du använder RequestContext.

Teknisk karaktär

Tekniskt sett görs dessa variabler endast tillgängliga i mallkontexten om du använder RequestContext och kontextprocessorn 'django.contrib.auth.context_processors.auth' är aktiverad. Det finns i den standardgenererade inställningsfilen. För mer information, se :ref:``RequestContext docs <subclassing-context-requestcontext>`.

Användare¶

Vid rendering av en mall RequestContext lagras den för närvarande inloggade användaren, antingen en User-instans eller en AnonymousUser-instans, i mallvariabeln {{ user }}:

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

Denna mallkontextvariabel är inte tillgänglig om en RequestContext inte används.

Rättigheter¶

Den inloggade användarens behörigheter lagras i mallvariabeln {{ perms }}. Detta är en instans av django.contrib.auth.context_processors.PermWrapper, som är en mallvänlig proxy av behörigheter.

Att utvärdera en enattributsuppslagning av {{perms }} som en boolean är en proxy till User.has_module_perms(). Till exempel, för att kontrollera om den inloggade användaren har några behörigheter i appen foo:

{% if perms.foo %}

Att utvärdera en två-nivå-attributuppslagning som en boolean är en proxy till User.has_perm(). Till exempel för att kontrollera om den inloggade användaren har behörigheten foo.add_vote:

{% if perms.foo.add_vote %}

Här är ett mer komplett exempel på kontroll av behörigheter i en mall:

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

Det är också möjligt att slå upp behörigheter med {% if i %}-satser. Till exempel:

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

Hantera användare i administratören¶

När du har både django.contrib.admin och django.contrib.auth installerade, ger admin ett bekvämt sätt att visa och hantera användare, grupper och behörigheter. Användare kan skapas och tas bort som vilken Django-modell som helst. Grupper kan skapas och behörigheter kan tilldelas användare eller grupper. En logg över användares redigeringar av modeller som görs i admin lagras och visas också.

Skapa användare¶

Du bör se en länk till ”Användare” i avsnittet ”Auth” på huvudadministratörens indexsida. Administrationssidan ”Lägg till användare” skiljer sig från vanliga administrationssidor genom att du måste välja ett användarnamn och lösenord innan du kan redigera resten av användarens fält. Alternativt kan du på den här sidan välja ett användarnamn och inaktivera lösenordsbaserad autentisering för användaren.

Observera också: om du vill att ett användarkonto ska kunna skapa användare med hjälp av Django-adminsidan måste du ge dem behörighet att lägga till användare och ändra användare (dvs. behörigheterna ”Lägg till användare” och ”Ändra användare”). Om ett konto har behörighet att lägga till användare men inte att ändra dem, kommer det kontot inte att kunna lägga till användare. Varför inte? För att om du har behörighet att lägga till användare har du möjlighet att skapa superanvändare, som sedan i sin tur kan ändra andra användare. Så Django kräver lägg till och ändringsbehörigheter som en liten säkerhetsåtgärd.

Tänk noga igenom hur du låter användare hantera behörigheter. Om du ger en icke-superanvändare möjlighet att redigera användare är det i slutändan samma sak som att ge dem superanvändarstatus eftersom de kommer att kunna höja behörigheterna för användare inklusive sig själva!

Byte av lösenord¶

Användarlösenord visas inte i administratören (och lagras inte heller i databasen), men :doc:``Lagringsdetaljer för lösenord </topics/auth/passwords>` visas. När denna information visas finns en länk till ett formulär för lösenordsändring som gör det möjligt för administratörer att ändra eller ta bort användarlösenord.

Använda Djangos autentiseringssystem¶

`User`-objekt¶

Skapa användare¶

Skapa superanvändare¶

Byte av lösenord¶

Autentisering av användare¶

Behörigheter och auktorisering¶

Standardbehörighet¶

Grupper¶

Skapa behörigheter programmatiskt¶

Cachelagring av behörigheter¶

Proxy-modeller¶

Autentisering i webbförfrågningar¶

Så här loggar du in en användare¶

Välja backend för autentisering¶

Så här loggar du ut en användare¶

Begränsning av åtkomst till inloggade användare¶

Det råa sättet¶

Mixin `LoginRequiredMixin` mixin¶

Begränsa åtkomsten till inloggade användare som klarar ett test¶

Dekoratorn `permission_required` (tillstånd krävs)¶

Mixin `PermissionRequiredMixin` mixin¶

Omdirigering av obehöriga förfrågningar i klassbaserade vyer¶

Inaktivering av session vid byte av lösenord¶

Autentiseringsvyer¶

Använda vyerna¶

Alla autentiseringsvyer¶

Hjälpfunktioner¶

Inbyggda formulär¶

Autentiseringsdata i mallar¶

Användare¶

Rättigheter¶

Hantera användare i administratören¶

Skapa användare¶

Byte av lösenord¶

Additional Information

Support Django!

Contents

Getting help

Download:

Använda Djangos autentiseringssystem¶

User-objekt¶

Skapa användare¶

Skapa superanvändare¶

Byte av lösenord¶

Autentisering av användare¶

Behörigheter och auktorisering¶

Standardbehörighet¶

Grupper¶

Skapa behörigheter programmatiskt¶

Cachelagring av behörigheter¶

Proxy-modeller¶

Autentisering i webbförfrågningar¶

Så här loggar du in en användare¶

Välja backend för autentisering¶

Så här loggar du ut en användare¶

Begränsning av åtkomst till inloggade användare¶

Det råa sättet¶

Dekoratorn login_required (inloggning krävs)¶

Mixin LoginRequiredMixin mixin¶

Dekoratorn login_not_required¶

Begränsa åtkomsten till inloggade användare som klarar ett test¶

Dekoratorn permission_required (tillstånd krävs)¶

Mixin PermissionRequiredMixin mixin¶

Omdirigering av obehöriga förfrågningar i klassbaserade vyer¶

Inaktivering av session vid byte av lösenord¶

Autentiseringsvyer¶

Använda vyerna¶

Alla autentiseringsvyer¶

Hjälpfunktioner¶

Inbyggda formulär¶

Autentiseringsdata i mallar¶

Användare¶

Rättigheter¶

Hantera användare i administratören¶

Skapa användare¶

Byte av lösenord¶

Additional Information

Support Django!

Contents

Getting help

Download:

`User`-objekt¶

Dekoratorn `login_required` (inloggning krävs)¶

Mixin `LoginRequiredMixin` mixin¶

Dekoratorn `login_not_required`¶

Dekoratorn `permission_required` (tillstånd krävs)¶

Mixin `PermissionRequiredMixin` mixin¶