---
title: "Använda Djangos autentiseringssystem"
version: 6.0
locale: sv
source: https://docs.djangoproject.com/sv/6.0/topics/auth/default/
canonical: https://djangodocs.dev/sv/6.0/topics/auth/default/
---
# 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](/sv/6.0/topics/auth/customizing/) 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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.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'`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.is_superuser) eller admin [`'staff'`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.is_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:

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

Se [`full API-dokumentation`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User) 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()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.UserManager.create_user) hjälpfunktionen:

```pycon
>>> 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](#auth-admin).

### Skapa superanvändare

Skapa superanvändare med hjälp av kommandot [`createsuperuser`](/sv/6.0/ref/django-admin/#django-admin-createsuperuser):

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

*Windows*

```doscon
...\> 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`](/sv/6.0/ref/django-admin/#cmdoption-createsuperuser-username) eller [`--email`](/sv/6.0/ref/django-admin/#cmdoption-createsuperuser-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](/sv/6.0/topics/auth/passwords/) 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*`](/sv/6.0/ref/django-admin/#django-admin-changepassword) 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.

You can also change a password programmatically, using
[`set_password()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.set_password):

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

Om du har Django admin installerat kan du också ändra användarens lösenord på [autentiseringssystemets adminsidor](#auth-admin).

Django tillhandahåller även [views](#built-in-auth-views) och [forms](#built-in-auth-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](#session-invalidation-on-password-change) för mer information.

### Autentisering av användare

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

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

*Asynkron version*: `aauthenticate()`

Use [`authenticate()`](#django.contrib.auth.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](/sv/6.0/topics/auth/customizing/#authentication-backends), and returns a
[`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.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`](/sv/6.0/ref/exceptions/#django.core.exceptions.PermissionDenied), it
returns `None`. For example:

```
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`](/sv/6.0/ref/request-response/#django.http.HttpRequest) som skickas till `authenticate()`-metoden i autentiseringsbackends.

> **Note**
>
> Detta är ett lågnivåsätt att autentisera en uppsättning referenser; det används till exempel av [`RemoteUserMiddleware`](/sv/6.0/ref/middleware/#django.contrib.auth.middleware.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`](#django.contrib.auth.views.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()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_view_permission), [`has_add_permission()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_add_permission), [`has_change_permission()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_change_permission) och [`has_delete_permission()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_delete_permission) som tillhandahålls av klassen [`ModelAdmin`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin) är det möjligt att anpassa behörigheter för olika objektinstanser av samma typ.

[`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User)-objekt har två many-to-many-fält: `groups` och `user_permissions`. [`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User)-objekt kan komma åt sina relaterade objekt på samma sätt som alla andra [Django model](/sv/6.0/topics/db/models/):

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

### Standardbehörighet

När `django.contrib.auth` är listad i din [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-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`](/sv/6.0/ref/django-admin/#django-admin-migrate); första gången du kör `migrate` efter att ha lagt till `django.contrib.auth` i [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-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`](/sv/6.0/ref/django-admin/#django-admin-migrate) (funktionen som skapar behörigheter är kopplad till signalen [`post_migrate`](/sv/6.0/ref/signals/#django.db.models.signals.post_migrate)).

Anta att du har en applikation med en [`app_label`](/sv/6.0/ref/models/options/#django.db.models.Options.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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.Permission) är sällan direkt åtkomlig.

### Grupper

[`django.contrib.auth.models.Group`](/sv/6.0/ref/contrib/auth/#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 [custom permissions](/sv/6.0/topics/auth/customizing/#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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User) via dess attribut `user_permissions` eller till en [`Group`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.Group) via dess attribut `permissions`.

> **Proxy-modeller behöver sin egen innehållstyp**
>
> Om du vill skapa [behörigheter för en proxymodell](#proxy-models-permissions-topic), skicka `for_concrete_model=False` till [`ContentTypeManager.get_for_model()`](/sv/6.0/ref/contrib/contenttypes/#django.contrib.contenttypes.models.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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.backends.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")]
```

```pycon
>>> # 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](/sv/6.0/topics/http/sessions/) och middleware för att koppla autentiseringssystemet till [`request-objekt`](/sv/6.0/ref/request-response/#django.http.HttpRequest).

Dessa tillhandahåller ett [`request.user`](/sv/6.0/ref/request-response/#django.http.HttpRequest.user)-attribut och en [`request.auser`](/sv/6.0/ref/request-response/#django.http.HttpRequest.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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser), annars kommer det att vara en instans av [`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User).

Du kan skilja dem åt med [`is_authenticated`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.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()`](#django.contrib.auth.login)-funktion.

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

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

*Asynkron version*: `alogin()`

To log a user in, from a view, use [`login()`](#django.contrib.auth.login). It
takes an [`HttpRequest`](/sv/6.0/ref/request-response/#django.http.HttpRequest) object and a
[`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User) object.
[`login()`](#django.contrib.auth.login) saves the user’s ID in the session,
using Django’s session framework.

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

This example shows how you might use both
[`authenticate()`](#django.contrib.auth.authenticate) and
[`login()`](#django.contrib.auth.login):

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

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

#### 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](/sv/6.0/topics/auth/customizing/#authentication-backends) kan hämta användarens uppgifter vid en framtida begäran. Den autentiseringsbackend som ska sparas i sessionen väljs enligt följande:

1. Använd värdet för det valfria argumentet `backend`, om det anges.
2. Use the value of the `user.backend` attribute, if present. This allows
   pairing [`authenticate()`](#django.contrib.auth.authenticate) and
   [`login()`](#django.contrib.auth.login):
   [`authenticate()`](#django.contrib.auth.authenticate)
   sets the `user.backend` attribute on the user object it returns.
3. Använd `backend` i [`AUTHENTICATION_BACKENDS`](/sv/6.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), om det bara finns en.
4. 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`](/sv/6.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS)), inte den faktiska backendklassen.

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

#### `logout(request)`

#### `alogout(request)`

*Asynkron version*: `alogout()`

To log out a user who has been logged in via
[`django.contrib.auth.login()`](#django.contrib.auth.login), use
[`django.contrib.auth.logout()`](#django.contrib.auth.logout) within your view. It takes an
[`HttpRequest`](/sv/6.0/ref/request-response/#django.http.HttpRequest) object and has no return value.
Example:

```
from django.contrib.auth import logout

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

Note that [`logout()`](#django.contrib.auth.logout) doesn’t throw any errors if
the user wasn’t logged in.

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

### 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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.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)`

Som en genväg kan du använda den praktiska [`login_required()`](#django.contrib.auth.decorators.login_required) decorator:

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

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

[`login_required()`](#django.contrib.auth.decorators.login_required) gör följande:

- Om användaren inte är inloggad, omdirigera till [`settings.LOGIN_URL`](/sv/6.0/ref/settings/#std-setting-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()`](#django.contrib.auth.decorators.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()`](#django.contrib.auth.decorators.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`](/sv/6.0/ref/settings/#std-setting-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`](/sv/6.0/ref/settings/#std-setting-LOGIN_URL) accepterar även namn på vyfunktioner och [named URL patterns](/sv/6.0/topics/http/urls/#naming-url-patterns). Detta gör att du fritt kan ändra din inloggningsvy i din URLconf utan att behöva uppdatera inställningen.

> **Note**
>
> Dekoratorn `login_required` kontrollerar INTE flaggan `is_active` på en användare, men standardinställningen [`AUTHENTICATION_BACKENDS`](/sv/6.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) avvisar inaktiva användare.

> **See also**
>
> 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()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.views.decorators.staff_member_required) dekoratorn är ett användbart alternativ till `login_required()`.

#### Mixin `LoginRequiredMixin` mixin

När du använder [klassbaserade vyer](/sv/6.0/topics/class-based-views/) 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`

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`](#django.contrib.auth.mixins.AccessMixin.raise_exception)-parametern.

Du kan ställa in någon av parametrarna i [`AccessMixin`](#django.contrib.auth.mixins.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"
```

> **Note**
>
> Precis som dekoratorn `login_required` kontrollerar denna mixin INTE flaggan `is_active` på en användare, men standardinställningen [`AUTHENTICATION_BACKENDS`](/sv/6.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) avvisar inaktiva användare.

#### Dekoratorn `login_not_required`

När [`LoginRequiredMiddleware`](/sv/6.0/ref/middleware/#django.contrib.auth.middleware.LoginRequiredMiddleware) är installerad kräver alla vyer autentisering som standard. Vissa vyer, t.ex. inloggningsvyn, kan behöva inaktivera detta beteende.

#### `login_not_required()`

Tillåter oautentiserade förfrågningar till denna vy när [`LoginRequiredMiddleware`](/sv/6.0/ref/middleware/#django.contrib.auth.middleware.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`](/sv/6.0/ref/request-response/#django.http.HttpRequest.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')`

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()`](#django.contrib.auth.decorators.user_passes_test) tar ett obligatoriskt argument: en anropbar som tar ett [`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User)-objekt och returnerar `True` om användaren får visa sidan. Observera att [`user_passes_test()`](#django.contrib.auth.decorators.user_passes_test) inte automatiskt kontrollerar att [`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User) inte är anonym.

[`user_passes_test()`](#django.contrib.auth.decorators.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`](/sv/6.0/ref/settings/#std-setting-LOGIN_URL) om du inte anger någon.

**`omdirigering_fältnamn`**

  Samma som för [`login_required()`](#django.contrib.auth.decorators.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): ...
```

#### `class UserPassesTestMixin`

När du använder [klassbaserade vyer](/sv/6.0/topics/class-based-views/) kan du använda `UserPassesTestMixin` för att göra detta.

#### `test_func()`

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`](#django.contrib.auth.mixins.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()`

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()`](#django.contrib.auth.mixins.UserPassesTestMixin.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)`

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()`](#django.contrib.auth.decorators.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()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.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.

Note that [`permission_required()`](#django.contrib.auth.decorators.permission_required)
also takes an optional `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()`](#django.contrib.auth.decorators.login_required)-dekoratorn är `login_url` standardvärdet för [`settings.LOGIN_URL`](/sv/6.0/ref/settings/#std-setting-LOGIN_URL).

Om parametern `raise_exception` anges, kommer dekoratorn att höja [`PermissionDenied`](/sv/6.0/ref/exceptions/#django.core.exceptions.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()`](#django.contrib.auth.decorators.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`](#django.contrib.auth.views.LoginView)’s `redirect_authenticated_user=True` och den inloggade användaren inte har alla nödvändiga behörigheter.

#### Mixin `PermissionRequiredMixin` mixin

För att tillämpa behörighetskontroller på [klassbaserade vyer](/sv/6.0/ref/class-based-views/) kan du använda `PermissionRequiredMixin`:

#### `class PermissionRequiredMixin`

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`](#django.contrib.auth.mixins.AccessMixin) för att anpassa hanteringen av obehöriga användare.

Du kan också åsidosätta dessa metoder:

#### `get_permission_required()`

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

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()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perms) with the
list of permissions returned by [`get_permission_required()`](#django.contrib.auth.mixins.PermissionRequiredMixin.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](/sv/6.0/ref/class-based-views/) 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`](#django.contrib.auth.mixins.AccessMixin.raise_exception).

#### `class AccessMixin`

#### `login_url`

Default return value for [`get_login_url()`](#django.contrib.auth.mixins.AccessMixin.get_login_url). Defaults to `None`
in which case [`get_login_url()`](#django.contrib.auth.mixins.AccessMixin.get_login_url) falls back to
[`settings.LOGIN_URL`](/sv/6.0/ref/settings/#std-setting-LOGIN_URL).

#### `permission_denied_message`

Standardavkastningsvärde för [`get_permission_denied_message()`](#django.contrib.auth.mixins.AccessMixin.get_permission_denied_message). Standardvärdet är en tom sträng.

#### `redirect_field_name`

Standardreturvärde för [`get_redirect_field_name()`](#django.contrib.auth.mixins.AccessMixin.get_redirect_field_name). Standardvärdet är `"next"`.

#### `raise_exception`

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

#### `get_login_url()`

Returnerar URL:en som användare som inte klarar testet kommer att omdirigeras till. Returnerar [`login_url`](#django.contrib.auth.mixins.AccessMixin.login_url) om den är inställd, eller [`settings.LOGIN_URL`](/sv/6.0/ref/settings/#std-setting-LOGIN_URL) annars.

#### `get_permission_denied_message()`

När [`raise_exception`](#django.contrib.auth.mixins.AccessMixin.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`](#django.contrib.auth.mixins.AccessMixin.permission_denied_message) som standard.

#### `get_redirect_field_name()`

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`](#django.contrib.auth.mixins.AccessMixin.redirect_field_name) som standard.

#### `handle_no_permission()`

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

If your [`AUTH_USER_MODEL`](/sv/6.0/ref/settings/#std-setting-AUTH_USER_MODEL) inherits from
[`AbstractBaseUser`](/sv/6.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser) or implements its own
[`get_session_auth_hash()`](/sv/6.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash)
method, authenticated sessions will include the hash returned by this function.
In the [`AbstractBaseUser`](/sv/6.0/topics/auth/customizing/#django.contrib.auth.models.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.

Standardvyerna för lösenordsändring som ingår i Django, [`PasswordChangeView`](#django.contrib.auth.views.PasswordChangeView) och vyn `user_change_password` i [`django.contrib.auth`](/sv/6.0/topics/auth/#module-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()`](#django.contrib.auth.update_session_auth_hash).

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

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

> **Note**
>
> Since
> [`get_session_auth_hash()`](/sv/6.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash)
> is based on [`SECRET_KEY`](/sv/6.0/ref/settings/#std-setting-SECRET_KEY), secret key values must be
> rotated to avoid invalidating existing sessions when updating your site to
> use a new secret. See [`SECRET_KEY_FALLBACKS`](/sv/6.0/ref/settings/#std-setting-SECRET_KEY_FALLBACKS) for details.

### 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](#built-in-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](#all-authentication-views).

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

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

Vyerna ger ett URL-namn för enklare referens. Se [URL-dokumentationen](/sv/6.0/topics/http/urls/) 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](/sv/6.0/topics/class-based-views/), 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](#using-the-views).

#### `class LoginView`

**Namn på webbadress:** `login`

Se [URL-dokumentationen](/sv/6.0/topics/http/urls/) 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`](/sv/6.0/ref/settings/#std-setting-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()`](#django.contrib.auth.views.LoginView.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`](#django.contrib.auth.forms.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`.

> **Warning**
>
> 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](https://robinlinus.github.io/socialmedia-leak/)” 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()`](#django.contrib.auth.decorators.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()`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_host), som är säkra för omdirigering efter inloggning. Standardvärdet är en tom [`set`](https://docs.python.org/3/library/stdtypes.html#set).

#### `get_default_redirect_url()`

Returnerar den URL som ska omdirigeras till efter inloggning. Standardimplementeringen löser och returnerar [`next_page`](#django.contrib.auth.views.LoginView.next_page) om den är inställd, eller [`LOGIN_REDIRECT_URL`](/sv/6.0/ref/settings/#std-setting-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`](/sv/6.0/ref/settings/#std-setting-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`](/sv/6.0/ref/forms/api/#django.forms.Form)-objekt som representerar [`AuthenticationForm`](#django.contrib.auth.forms.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`](/sv/6.0/ref/contrib/sites/#django.contrib.sites.models.Site), enligt inställningen [`SITE_ID`](/sv/6.0/ref/settings/#std-setting-SITE_ID). Om du inte har installerat webbplatsramverket kommer detta att ställas in till en instans av [`RequestSite`](/sv/6.0/ref/contrib/sites/#django.contrib.sites.requests.RequestSite), som härleder webbplatsnamnet och domänen från den aktuella [`HttpRequest`](/sv/6.0/ref/request-response/#django.http.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']`](/sv/6.0/ref/request-response/#django.http.HttpRequest.META). För mer information om webbplatser, se [Ramverket för ”webbplatser”](/sv/6.0/ref/contrib/sites/).

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:

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

{% block content %}

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

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

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

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

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

{% endblock %}
```

Om du har anpassat autentiseringen (se [Customizing Authentication](/sv/6.0/topics/auth/customizing/)) 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`

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`](/sv/6.0/ref/settings/#std-setting-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`](#django.contrib.auth.views.LogoutView.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()`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_host), som är säkra för omdirigering efter utloggning. Standardvärdet är en tom [`set`](https://docs.python.org/3/library/stdtypes.html#set).

**Template context:**

- `title`: Strängen ”Logged out”, lokaliserad.
- `site`: Den aktuella [`Site`](/sv/6.0/ref/contrib/sites/#django.contrib.sites.models.Site), enligt inställningen [`SITE_ID`](/sv/6.0/ref/settings/#std-setting-SITE_ID). Om du inte har installerat webbplatsramverket kommer detta att ställas in till en instans av [`RequestSite`](/sv/6.0/ref/contrib/sites/#django.contrib.sites.requests.RequestSite), som härleder webbplatsnamnet och domänen från den aktuella [`HttpRequest`](/sv/6.0/ref/request-response/#django.http.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']`](/sv/6.0/ref/request-response/#django.http.HttpRequest.META). För mer information om webbplatser, se [Ramverket för ”webbplatser”](/sv/6.0/ref/contrib/sites/).

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

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`](/sv/6.0/ref/settings/#std-setting-LOGIN_URL) om det inte anges.

#### `class PasswordChangeView`

**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`](#django.contrib.auth.forms.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`

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

**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()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.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`](#django.contrib.auth.forms.PasswordResetForm) och använda attributet `form_class`.

> **Note**
>
> 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](https://pypi.org/project/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`](#django.contrib.auth.forms.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 [`DEFAULT_FROM_EMAIL`](/sv/6.0/ref/settings/#std-setting-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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.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']`](/sv/6.0/ref/request-response/#django.http.HttpRequest.META). För mer information om webbplatser, se [Ramverket för ”webbplatser”](/sv/6.0/ref/contrib/sites/).
- `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):

```html+django
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`

**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`](#django.contrib.auth.views.PasswordResetView) inte har en explicit `uccess_url` URL inställd.

> **Note**
>
> 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`

**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`](/sv/6.0/ref/settings/#std-setting-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`](#django.contrib.auth.forms.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`

**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')`

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`](/sv/6.0/ref/settings/#std-setting-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`](#module-django.contrib.auth.forms):

> **Note**
>
> De inbyggda autentiseringsformulären gör vissa antaganden om den användarmodell som de arbetar med. Om du använder en [anpassad användarmodell](/sv/6.0/topics/auth/customizing/#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](/sv/6.0/topics/auth/customizing/#custom-users-and-the-built-in-auth-forms).

#### `class AdminPasswordChangeForm`

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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.set_unusable_password), som blockerar användaren från att logga in med lösenordsbaserad autentisering.

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

#### `class AdminUserCreationForm`

Ett formulär som används i admin-gränssnittet för att skapa en ny användare. Ärver från [`UserCreationForm`](#django.contrib.auth.forms.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()`](/sv/6.0/topics/auth/passwords/#django.contrib.auth.password_validation.validate_password), and
sets the user’s password using
[`set_password()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.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()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.set_unusable_password).

#### `class AuthenticationForm`

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

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`](/sv/6.0/ref/exceptions/#django.core.exceptions.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`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.backends.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`

En [`ModelForm`](/sv/6.0/topics/forms/modelforms/#django.forms.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.

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()`](/sv/6.0/topics/auth/passwords/#django.contrib.auth.password_validation.validate_password), and
sets the user’s password using
[`set_password()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.set_password).

#### `class PasswordChangeForm`

Ett formulär för att tillåta en användare att ändra sitt lösenord.

#### `class PasswordResetForm`

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

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`](#django.contrib.auth.views.PasswordResetView) skickar till sin e-postkontext.

#### `class SetPasswordForm`

Ett formulär som låter en användare ändra sitt lösenord utan att ange det gamla lösenordet.

#### `class UserChangeForm`

Ett formulär som används i administratörsgränssnittet för att ändra en användares information och behörigheter.

#### `class UserCreationForm`

Ärver från [`BaseUserCreationForm`](#django.contrib.auth.forms.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](/sv/6.0/ref/templates/api/) när du använder [`RequestContext`](/sv/6.0/ref/templates/api/#django.template.RequestContext).

> **Teknisk karaktär**
>
> Tekniskt sett görs dessa variabler endast tillgängliga i mallkontexten om du använder [`RequestContext`](/sv/6.0/ref/templates/api/#django.template.RequestContext) och kontextprocessorn `'django.contrib.auth.context_processors.auth'` är aktiverad. Det finns i den standardgenererade inställningsfilen. För mer information, se [RequestContext docs](/sv/6.0/ref/templates/api/#subclassing-context-requestcontext).

#### Användare

Vid rendering av en mall [`RequestContext`](/sv/6.0/ref/templates/api/#django.template.RequestContext) lagras den för närvarande inloggade användaren, antingen en [`User`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User)-instans eller en [`AnonymousUser`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser)-instans, i mallvariabeln `{{ user }}`:

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

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()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.has_module_perms). Till exempel, för att kontrollera om den inloggade användaren har några behörigheter i appen `foo`:

```html+django
{% if perms.foo %}
```

Att utvärdera en två-nivå-attributuppslagning som en boolean är en proxy till [`User.has_perm()`](/sv/6.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perm). Till exempel för att kontrollera om den inloggade användaren har behörigheten `foo.add_vote`:

```html+django
{% if perms.foo.add_vote %}
```

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

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

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

```html+django
{% 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 [Lagringsdetaljer för lösenord](/sv/6.0/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.