Autentisering¶

Användarregistrering¶

Standardinställningen för Weblate är att använda python-social-auth, ett formulär på webbplatsen för att hantera registrering av nya användare. Efter att ha bekräftat sin e-postadress kan en ny användare bidra eller autentisera sig genom att använda en av tredjepartstjänsterna.

Du kan också inaktivera registrering av nya användare med REGISTRATION_OPEN.

Autentiseringsförsöken är föremål för Hastighetsbegränsande.

Autentiseringsbackend¶

Weblate använder Django för autentisering. Detta inkluderar inbyggd lösenordsbaserad autentisering, social autentisering och tredjepartsautentiseringsbackends för Django.

Genom att använda Djangos inbyggda autentisering kan du importera användardatabasen från andra Django-baserade projekt (se Migrera från Pootle).

Se även

Autentiseringsinställningar beskriver hur man konfigurerar autentisering i den officiella Docker-bilden.

Autentisering med lösenord¶

Standardfilen settings.py innehåller en rimlig uppsättning AUTH_PASSWORD_VALIDATORS som säkerställer att svaga lösenord inte tillåts. Du kan anpassa denna inställning så att den överensstämmer med din lösenordspolicy.

Dessutom kan du också installera django-zxcvbn-password-validator som ger ganska realistiska uppskattningar av lösenordets svårighetsgrad och gör det möjligt att avvisa lösenord som ligger under en viss tröskel.

Se även

SAML-autentisering¶

Added in version 4.1.1.

Förändrat i version 5.12: Beroendena för SAML-autentisering ingår inte längre i standardtilläggen all. Du måste inkludera saml när du installerar Weblate-paketet med pip (uv pip install Weblate[all,saml]).

Följ instruktionerna för Python Social Auth för konfiguration. Viktiga skillnader:

Weblate stöder en enda IDP som måste kallas weblate i SOCIAL_AUTH_SAML_ENABLED_IDPS.
SAML XML-metadata-URL:en är /accounts/metadata/saml/, vilket också är ett entitets-ID.
Inloggningsadressen är /accounts/complete/saml/ (även känd som ACS-adress).
Följande inställningar fylls i automatiskt: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Exempel på konfiguration:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.email.EmailAuth",
    "social_core.backends.saml.SAMLAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_SAML_SP_ENTITY_ID = f"https://{SITE_DOMAIN}/accounts/metadata/saml/"
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT = "-----BEGIN CERTIFICATE-----"
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY = "-----BEGIN PRIVATE KEY-----"
SOCIAL_AUTH_SAML_ENABLED_IDPS = {
    "weblate": {
        "entity_id": "https://idp.testshib.org/idp/shibboleth",
        "url": "https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO",
        "x509cert": "MIIEDjCCAvagAwIBAgIBADA ... 8Bbnl+ev0peYzxFyF5sQA==",
    }
}
SOCIAL_AUTH_SAML_ORG_INFO = {
    "en-US": {
        "name": "example",
        "displayname": "Example Inc.",
        "url": "http://example.com"
    }
}
SOCIAL_AUTH_SAML_TECHNICAL_CONTACT = {
    "givenName": "Tech Gal",
    "emailAddress": "technical@example.com"
}
SOCIAL_AUTH_SAML_SUPPORT_CONTACT = {
    "givenName": "Support Guy",
    "emailAddress": "support@example.com"
}

Standardkonfigurationen extraherar användarinformation från följande attribut. Konfigurera din IdP så att den tillhandahåller dessa:

Attribut	SAML URI-referens
Fullständigt namn	`urn:oid:2.5.4.3`
Förnamn	`urn:oid:2.5.4.42`
Efternamn	`urn:oid:2.5.4.4`
E-post	`urn:oid:0.9.2342.19200300.100.1.3`
Användarnamn	`urn:oid:0.9.2342.19200300.100.1.1`

När du konfigurerar Weblate SP i din IdP rekommenderas det att välja persistent Namn-ID-format.

Råd

Exemplet ovan och Docker-bilden definierar en IdP som heter weblate. Du kan behöva konfigurera denna sträng som Relay i din IdP.

Observera

Weblate-autentisering är beroende av att parametern RelayState skickas genom autentiseringsprocessen. Detta måste konfigureras med vissa identitetsleverantörer:

Hur man skickar ett anpassat RelayState med Okta

Se även

Autentisering med LDAP¶

LDAP-autentisering kan bäst uppnås med hjälp av paketet django-auth-ldap. Du kan installera det på vanligt sätt:

# Using PyPI
uv pip install 'django-auth-ldap>=1.3.0'

# Using apt-get
apt-get install python-django-auth-ldap

Råd

Detta paket ingår i Docker-containern, se Installera med Docker.

Observera

Det finns vissa inkompatibiliteter i Python LDAP 3.1.0-modulen, vilket kan hindra dig från att använda den versionen. Om du får felmeddelandet AttributeError: ’module’ object has no attribute ’_trace_level’ kan det hjälpa att nedgradera python-ldap till 3.0.0.

När du har installerat paketet kan du koppla det till Djangos autentisering:

# Add LDAP backed, keep Django one if you want to be able to sign in
# even without LDAP for admin account
AUTHENTICATION_BACKENDS = (
    "django_auth_ldap.backend.LDAPBackend",
    "weblate.accounts.auth.WeblateUserBackend",
)

# LDAP server address
AUTH_LDAP_SERVER_URI = "ldaps://ldap.example.net"

# DN to use for authentication
AUTH_LDAP_USER_DN_TEMPLATE = "cn=%(user)s,o=Example"
# Depending on your LDAP server, you might use a different DN
# like:
# AUTH_LDAP_USER_DN_TEMPLATE = 'ou=users,dc=example,dc=com'

# List of attributes to import from LDAP upon sign in
# Weblate stores full name of the user in the full_name attribute
AUTH_LDAP_USER_ATTR_MAP = {
    "full_name": "name",
    # Use the following if your LDAP server does not have full name
    # Weblate will merge them later
    # 'first_name': 'givenName',
    # 'last_name': 'sn',
    # Email is required for Weblate (used in VCS commits)
    "email": "mail",
}

# Hide the registration form
REGISTRATION_OPEN = False

Observera

Du bör ta bort 'social_core.backends.email.EmailAuth' från inställningen AUTHENTICATION_BACKENDS, annars kommer användare att kunna ställa in sitt lösenord i Weblate och autentisera sig med det. Det är fortfarande nödvändigt att behålla 'weblate.accounts.auth.WeblateUserBackend' för att skapa behörigheter och underlätta för anonyma användare. Det gör det också möjligt att logga in med ett lokalt administratörskonto, om du har skapat ett sådant (t.ex. med createadmin).

Använda bindlösenord¶

Om du inte kan använda direktbindning för autentisering måste du använda sökning och ange en användare att binda för sökningen. Till exempel:

import ldap
from django_auth_ldap.config import LDAPSearch

AUTH_LDAP_BIND_DN = ""
AUTH_LDAP_BIND_PASSWORD = ""
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "ou=users,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(uid=%(user)s)"
)

Active Directory-integration¶

import ldap
from django_auth_ldap.config import LDAPSearch, NestedActiveDirectoryGroupType

AUTH_LDAP_BIND_DN = "CN=ldap,CN=Users,DC=example,DC=com"
AUTH_LDAP_BIND_PASSWORD = "password"

# User and group search objects and types
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "CN=Users,DC=example,DC=com", ldap.SCOPE_SUBTREE, "(sAMAccountName=%(user)s)"
)

# Make selected group a superuser in Weblate
AUTH_LDAP_USER_FLAGS_BY_GROUP = {
    # is_superuser means user has all permissions
    "is_superuser": "CN=weblate_AdminUsers,OU=Groups,DC=example,DC=com",
}

# Map groups from AD to Weblate
AUTH_LDAP_GROUP_SEARCH = LDAPSearch(
    "OU=Groups,DC=example,DC=com", ldap.SCOPE_SUBTREE, "(objectClass=group)"
)
AUTH_LDAP_GROUP_TYPE = NestedActiveDirectoryGroupType()
AUTH_LDAP_FIND_GROUP_PERMS = True

# Optionally enable group mirroring from LDAP to Weblate
# AUTH_LDAP_MIRROR_GROUPS = True

Se även

Autentisering med CAS¶

CAS-autentisering kan uppnås med hjälp av ett paket som Django CAS NG.

Steg ett är att avslöja användarens e-postfält via CAS. Detta måste konfigureras på själva CAS-servern och kräver att du kör minst CAS v2, eftersom CAS v1 inte stöder attribut alls.

Steg två är att uppdatera Weblate så att den använder din CAS-server och dina attribut.

För att installera Django CAS NG:

uv pip install django-cas-ng

När du har installerat paketet kan du koppla det till Djangos autentiseringssystem genom att ändra filen settings.py:

# Add CAS backed, keep the Django one if you want to be able to sign in
# even without LDAP for the admin account
AUTHENTICATION_BACKENDS = (
    "django_cas_ng.backends.CASBackend",
    "weblate.accounts.auth.WeblateUserBackend",
)

# CAS server address
CAS_SERVER_URL = "https://cas.example.net/cas/"

# Add django_cas_ng somewhere in the list of INSTALLED_APPS
INSTALLED_APPS = (..., "django_cas_ng")

Slutligen kan en signal användas för att mappa e-postfältet till användarobjektet. För att detta ska fungera måste du importera signalen från paketet django-cas-ng och koppla din kod till denna signal. Att göra detta i inställningsfilen kan orsaka problem, därför rekommenderas det att placera den:

I din appkonfigurations django.apps.AppConfig.ready()-metod
I projektets urls.py-fil (när inga modeller finns)

from django_cas_ng.signals import cas_user_authenticated
from django.dispatch import receiver


@receiver(cas_user_authenticated)
def update_user_email_address(sender, user=None, attributes=None, **kwargs):
    # If your CAS server does not always include the email attribute
    # you can wrap the next two lines of code in a try/catch block.
    user.email = attributes["email"]
    user.save()

Konfigurera tredjeparts Django-autentisering¶

I allmänhet bör alla Django-autentiseringsplugins fungera med Weblate. Följ bara instruktionerna för pluginen och kom ihåg att behålla Weblate-användarbackend installerad.

Se även

Autentisering med LDAP
Autentisering med CAS

Vanligtvis består installationen av att lägga till en autentiseringsbackend till AUTHENTICATION_BACKENDS och installera en autentiseringsapp (om det finns någon) i INSTALLED_APPS:

AUTHENTICATION_BACKENDS = (
    # Add authentication backend here
    "weblate.accounts.auth.WeblateUserBackend",
)

INSTALLED_APPS += (
    # Install authentication app here
)

Tvåfaktorsautentisering¶

Added in version 5.7.

Råd

Tvåfaktorsautentisering lägger till ytterligare ett säkerhetslager till ditt konto genom att kräva mer än bara ett lösenord för att logga in.

Weblate stöder följande andra faktorer:

Säkerhetsnycklar (WebAuthn)

Både passnycklar och säkerhetsnycklar stöds.

Passkeys validerar din identitet med hjälp av touch, ansiktsigenkänning, ett enhetslösenord eller en PIN-kod, eftersom de inkluderar användarverifiering.

Säkerhetsnycklar är WebAuthn-autentiseringsuppgifter som endast kan användas som en andra autentiseringsfaktor, och dessa validerar endast användarens närvaro.

Autentiseringsappar (TOTP)

Autentiseringsappar och webbläsartillägg som Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator etc. genererar tidsbaserade engångslösenord som används som en andra faktor för att verifiera din identitet när du ombeds göra det vid inloggningen.

Återställningskoder

Återställningskoder kan användas för att komma åt ditt konto om du förlorar åtkomsten till din enhet och inte kan ta emot tvåfaktorsautentiseringskoder.

Förvara dina återställningskoder lika säkert som ditt lösenord. Vi rekommenderar att du sparar dem med en lösenordshanterare som Bitwarden, 1Password, Authy eller Keeper.

Varje användare kan konfigurera detta i Konto och en andra faktor kommer att krävas för inloggning utöver den befintliga autentiseringsmetoden.

Detta kan tillämpas för användare på projektnivå (se Tvingande tvåfaktorsautentisering) eller teamnivå.

Behörigheterna för ett team med tvingande tvåfaktorsautentisering kommer inte att tillämpas på användare som inte har den konfigurerad.

Autentisering¶

Användarregistrering¶

Autentiseringsbackend¶

Social autentisering¶

OpenID-autentisering¶

GitHub-autentisering¶

GitHub EE-autentisering¶

Bitbucket-autentisering¶

Google OAuth 2¶

Facebook OAuth 2¶

GitLab OAuth 2¶

Gitea OAuth 2¶

Microsoft Azure Active Directory¶

Slack¶

Överordnade autentiseringsmetoder och ikoner¶

Inaktivera lösenordsautentisering¶

Autentisering med lösenord¶

SAML-autentisering¶

Autentisering med LDAP¶

Använda bindlösenord¶

Active Directory-integration¶

Autentisering med CAS¶

Konfigurera tredjeparts Django-autentisering¶

Tvåfaktorsautentisering¶