Authentifizierung¶

Benutzerregistrierung¶

Die Standardeinstellung für Weblate ist die Verwendung von python-social-auth, einem Formular auf der Website zur Registrierung neuer Benutzer. Nach der Bestätigung ihrer E-Mail-Adresse kann ein neuer Benutzer einen Beitrag leisten oder sich mit einem der Dienste von Drittanbietern authentifizieren.

Sie können die Registrierung neuer Benutzer auch mit REGISTRATION_OPEN abschalten.

Die Authentifizierungsversuche unterliegen dem Ratenbegrenzung.

Authentifizierungs-Backends¶

Weblate setzt für die Authentifizierung auf Django. Dazu gehören integrierte Passwort-basierte Authentifizierung, soziale Authentifizierung und Drittanbieter-Authentifizierungs-Backends für Django.

Wenn Sie die integrierte Authentifizierung von Django nutzen, können Sie die Benutzerdatenbank anderer Django-basierter Projekte importieren (siehe Von Pootle migrieren).

Siehe auch

Authentifizierungseinstellungen beschreibt, wie man die Authentifizierung im offiziellen Docker-Image konfiguriert.

Teams von Identitätsanbietern¶

Added in version 2026.10.1.

Weblate kann während der sozialen Authentifizierung ausgewählte Teams aus externen Gruppenmitgliedschaften oder Anwendungsrollen synchronisieren. Die standardmäßigen nativen und Docker-Pipelines beinhalten die Synchronisierung nach den Authentifizierungsprüfungen und der Zwei-Faktor-Authentifizierung. Die Extraktion und Zuordnung sind deaktiviert, bis sie konfiguriert werden. Wenn Sie eine eigene Authentifizierungspipeline verwenden, fügen Sie social_core.pipeline.user.sync_groups nach allen Authentifizierungsprüfungen ein, einschließlich weblate.legal.pipeline.tos_confirm, wenn die Zustimmung zu den Nutzungsbedingungen aktiviert ist.

Ordnen Sie externe Kennungen den Listen mit den vorhandenen Weblate-Team-IDs zu. Die Team-IDs finden Sie in der URL der Adminoberfläche oder in der REST-API für Teams. Da sich Namen über Projekt- und Arbeitsbereichsgrenzen hinweg wiederholen können, werden sie nicht als Zuordnungsziele verwendet.

Für Microsoft Entra ID sollten Sie Anwendungsrollen bevorzugen:

SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_KEY = "roles"
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_MAP = {
    "Weblate.Translator": [42],
    "Weblate.Reviewer": [43],
}

Konfigurieren Sie den Anbieter so, dass er diese Rollen vergibt. Gruppenkennungen können stattdessen über GROUPS_KEY = "groups" ausgewählt werden. Bei einer Überschneidung von Gruppen schlägt die Authentifizierung fehl; Weblate ruft keine Zugehörigkeiten aus Microsoft Graph ab. Schränken Sie den vertrauenswürdigen Mandanten und den Aussteller ein, bevor Sie Berechtigungen erteilen, insbesondere beim Verwenden eines gemeinsamen Azure-Endpunkts.

Für generisches OpenID Connect oder Keycloak konfigurieren Sie einen wörtlichen Anspruchsnamen:

SOCIAL_AUTH_OIDC_GROUPS_KEY = "groups"
SOCIAL_AUTH_OIDC_GROUPS_MAP = {"translators": [42]}

SOCIAL_AUTH_KEYCLOAK_GROUPS_KEY = "groups"
SOCIAL_AUTH_KEYCLOAK_GROUPS_MAP = {"/organization/reviewers": [43]}

Für GitLab müssen Sie die Zugehörigkeitsabfrage explizit aktivieren:

SOCIAL_AUTH_GITLAB_GROUPS_ENABLED = True
SOCIAL_AUTH_GITLAB_GROUPS_MAP = {"organization/translators": [42]}

Durch das Aktivieren der Abfrage wird automatisch read_api angefordert, sofern nicht bereits read_api oder api angefordert wurde. Aktivieren Sie die entsprechende Berechtigung in den GitLab-OAuth-Anwendungseinstellungen neben read_user.

GitLab verwendet standardmäßig vollständige Gruppenpfade. Verwenden Sie stattdessen eindeutige numerische Gruppen-IDs, wenn sich Pfade ändern oder wiederverwendet werden könnten:

SOCIAL_AUTH_GITLAB_GROUPS_IDENTIFIER = "id"
SOCIAL_AUTH_GITLAB_GROUPS_MAP = {"12345": [42]}

Für SAML fügen Sie das Gruppenattribut und die Zuordnung zu jedem vorhandenen Eintrag unter SOCIAL_AUTH_SAML_ENABLED_IDPS hinzu:

SOCIAL_AUTH_SAML_ENABLED_IDPS["company"].update(
    {
        "attr_groups": "https://example.com/claims/groups",
        "groups_map": {"translators": [42]},
        "allow_groups": ["translators", "reviewers"],
    }
)

Alle Ziele in einer Zuordnung werden zu anbieterverwalteten Teams. Bei der Authentifizierung werden gewünschte Zugehörigkeiten hinzugefügt und veraltete verwaltete Zugehörigkeiten entfernt. Nicht zugehörige Teams und bestehende sprachliche Einschränkungen für die Zugehörigkeit bleiben erhalten. Änderungen werden im Auditprotokoll aufgezeichnet. Eine manuelle Zugehörigkeit zu einem verwalteten Team wird bei der nächsten Authentifizierung ersetzt. Ein Team darf nur von einem konfigurierten Anbieter oder SAML-IdP verwaltet werden; widersprüchliche Zuordnungen und nicht vorhandene Teams führen zu Fehlern, bevor sich die Zugehörigkeiten ändern. Es werden keine Teams automatisch erstellt.

Ein fehlender konfigurierter Claim führt zum Fehlschlagen der Authentifizierung. Wenn ein Anbieter Claims für Benutzer ohne Zuweisungen weglässt, aktivieren Sie explizit deren SOCIAL_AUTH_<BACKEND>_GROUPS_MISSING_AS_EMPTY-Einstellung. SAML verwendet groups_missing_as_empty im IdP-Eintrag. Eine leere Zugehörigkeitsliste entfernt alle vom Anbieter verwalteten Zugehörigkeiten. Ein leeres GROUPS_MAP deaktiviert die Zuweisung.

Anmeldebeschränkungen sind unabhängig von der Zuweisung. Konfigurieren Sie SOCIAL_AUTH_<BACKEND>_ALLOW_GROUPS so, dass die Zugehörigkeit zu einer der aufgeführten externen Gruppen oder Rollen erforderlich ist. Unbekannte Kennungen gewähren keine Berechtigungen, führen jedoch nicht zum Ablehnen der Anmeldung, sofern keine Zulassungsliste konfiguriert ist. Für bestehende CAS-Zulassungslisten sind keine neuen Einstellungen oder Pipeline-Einträge erforderlich.

Die Synchronisierung gilt für das Verlinken der Anmeldung, Registrierung und Authentifizierungsmethoden. Die Passwortzurücksetzung und Kontolöschung führen nicht zum Synchronisieren der Teams. Aktualisierungen erfolgen ausschließlich während der Authentifizierung; dabei werden Konten nicht im Hintergrund deaktiviert oder Zugriffsrechte entzogen. Bei der Synchronisierung werden keine Momentaufnahmen externer Zugehörigkeiten gespeichert.

Verwenden Sie bei Docker-Installationen Konfiguration über Umgebungsvariablen hinaus, um diese Python-Einstellungen festzulegen; für Team-Zuordnungen gibt es keine speziellen Umgebungsvariablen.

Siehe auch

External groups

Passwort-Authentifizierung¶

Standardmäßig kommt settings.py mit einem angemessenen Satz von AUTH_PASSWORD_VALIDATORS, der sicherstellt, dass schwache Passwörter nicht zugelassen werden. Sie können diese Einstellung an Ihre Passwort-Richtlinien anpassen.

Zusätzlich können Sie auch Django-ZXCVBN-Passwort-Validator installieren, das eine recht realistische Schätzung des Schwierigkeitsgrades von Passwörtern liefert und es ermöglicht, Passwörter unterhalb eines bestimmten Schwellenwertes abzulehnen.

Siehe auch

OpenID-Connect-Identitätsanbieter¶

Added in version 2026.11.

Weblate kann als optionaler OpenID-Connect-(OIDC)-Identitätsanbieter für andere Anwendungen fungieren. Dies ist unabhängig von der Anmeldung bei Weblate über einen externen OIDC-Anbieter.

Installieren Sie oidc extra (uv pip install Weblate[oidc]). Erzeugen Sie einen Signaturschlüssel und bewahren Sie ihn außerhalb der Versionsverwaltung auf:

openssl genrsa -out /path/to/oidc.key 4096

Aktivieren Sie OIDC_PROVIDER_ENABLED, fügen Sie die optionalen Anwendungen hinzu und konfigurieren Sie OAUTH2_PROVIDER in Ihren Einstellungen:

from pathlib import Path

OIDC_PROVIDER_ENABLED = True
INSTALLED_APPS += ["weblate.oidc", "oauth2_provider"]
OAUTH2_PROVIDER = {
    "OIDC_RSA_PRIVATE_KEY": Path("/path/to/oidc.key").read_text(encoding="utf-8"),
}

Führen Sie migrate aus, bevor Sie Weblate und dessen Worker starten. Bei deaktivierten Installationen werden diese Anwendungen, Abhängigkeiten und Datenbanktabellen nicht benötigt. Informationen zu Docker finden Sie unter WEBLATE_OIDC_PROVIDER_ENABLED.

Registrieren Sie jeden Client in Django-Verwaltung unter Anwendungen. Wählen Sie Autorisierungscode und RSA mit SHA-256. Bei Clients, die ein Geheimnis unterstützen, wählen Sie Vertraulich und kopieren Sie die generierte Client-ID und das Geheimnis sicher. Geheimnisse werden beim Speichern gehasht. Für Clients ohne Geheimnis wählen Sie Öffentlich; S256 PKCE ist für beide Client-Typen erforderlich. Registrieren Sie die genaue HTTPS-Callback-URL des Clients. Wählen Sie Autorisierung überspringen nur für vertrauenswürdige Clients; andere Clients benötigen eine Benutzereinwilligung, bevor sie auf Identitätsinformationen zugreifen können.

Der Aussteller ist die kanonische Weblate-Seiten-URL, gefolgt von /oidc, einschließlich eines URL_PREFIX. Die Entdeckungs-URL ist der Aussteller, gefolgt von /.well-known/openid-configuration. Konfigurieren Sie Clients so, dass sie diese Entdeckungs-URL , den Autorisierungscode-Ablauf, S256 PKCE und die Bereiche openid profile email verwenden. Die Authentifizierung über einen vertraulichen Client unterstützt HTTP Basic oder ein formcodiertes Client-Geheimnis. Für Zammad registrieren Sie einen öffentlichen Client, legen dessen Aussteller auf die Weblate-Aussteller-URL fest, wählen sub als UID-Feld aus, fordern openid profile email an und aktivieren PKCE. Der Callback lautet https://zammad.example.com/auth/openid_connect/callback. Nextclouds user_oidc-App kann einen vertraulichen Client mit der Entdeckungs-URL verwenden. Gemeinsames Abmelden und automatische Client-Registrierung werden nicht unterstützt.

Autorisierungsanfragen können per GET oder per POST mit Formularcodierung erfolgen. Clients tauschen Tokens aus und rufen über ihre Server die UserInfo ab.

Clients können mit prompt=login eine neue Authentifizierung anfordern oder die Gültigkeitsdauer in Sekunden der bestehenden Authentifizierung mit max_age begrenzen. Dieses Limit gilt auch beim Einreichen einer Einwilligung. Bei max_age=0 ist stets eine neue Anmeldung erforderlich. Bei prompt=none gibt Weblate login_required oder consent_required zurück, wenn für die Authentifizierung oder Einwilligung eine Benutzerinteraktion erforderlich ist.

Federated sign-in can reuse an upstream session without revealing its authentication time. These sign-ins omit auth_time from ID tokens and cannot satisfy prompt=login or max_age requests; Weblate returns login_required instead. Use a password-based sign-in or e-mail verification when fresh authentication is required. A failed freshness request does not prevent later ordinary federated sign-ins.

The sub claim is the Weblate user ID as a string, stable across username and e-mail changes. The profile scope adds preferred_username, name, and family_name; both name claims contain Weblate’s full name. The email scope adds email and email_verified. Verification is reported only when the current address has a recorded verification. Claims are available in ID tokens and from /oidc/userinfo/ using an access token.

When Rechtsmodul is installed, clients can additionally request the optional weblate:legal scope. It adds weblate_tos_version to ID tokens and UserInfo, containing the version the user actually accepted as an ISO date, for example "2026-09-01". Older accepted versions are returned unchanged; the claim is omitted when no acceptance is recorded. Reading it does not record consent or expose the acceptance timestamp, IP address, or user agent. Without the legal module, this scope is unavailable.

Receiving servers using the same legal package, such as wllegal, can use this date to match their legal version. They must explicitly trust the issuer and match the accepted version to their own documents before suppressing local confirmation. This provider only exposes the information; accepting shared consent on receiving Weblate servers requires separate integration.

New browser sessions created for OIDC sign-in expire after 60 seconds, including when sign-in requires Zwei-Faktor-Authentifizierung. Existing browser sessions keep their expiry policy. Sessions created before the provider recorded an authentication time require a fresh sign-in before authorizing a client. If the browser session expires while the consent page is open, submitting the form restarts sign-in and displays a new consent page. The earlier approval or denial is discarded; the user must submit the new form. Concurrent authorization attempts are tracked separately. Pending attempts expire after 15 minutes; starting more than 16 discards the oldest attempt.

Access and ID tokens last one hour. Refresh tokens rotate on use and expire after 30 days of inactivity beyond their associated access token’s expiry. ID tokens retain the original authentication time across refreshes, including its absence for federated sign-ins, even when the user signs in again elsewhere. Reusing an already rotated refresh token revokes its token family. Tokens work independently of the browser session and do not authorize Weblate REST API access. Account removal deletes provider credentials, and inactive accounts cannot authorize or use provider tokens. Celery periodically cleans expired credentials.

To rotate signing keys, replace OIDC_RSA_PRIVATE_KEY and retain old private keys in OIDC_RSA_PRIVATE_KEYS_INACTIVE until outstanding ID tokens and cached key sets have expired. Only public key material is published by JWKS.

When migrating a client from SAML, explicitly map its existing identities to the OIDC issuer and subject. Do not assume SAML NameIDs equal OIDC subjects, or link accounts solely by matching e-mail addresses. For weblate.org, existing accounts are linked by persistent SAML provider/identity pairs; its client integration and identity mapping require a separate migration.

SAML-Authentifizierung¶

Added in version 4.1.1.

Geändert in Version 5.12: Die Abhängigkeiten für die SAML-Authentifizierung sind nicht mehr in den standardmäßigen Extras all enthalten. Sie müssen saml einbinden, während Sie das Weblate-Paket mit pip installieren (uv pip install Weblate[all,saml]).

Bitte folgen Sie den Anweisungen von Python Social Auth für die Konfiguration. Bedeutende Unterschiede:

Weblate unterstützt einen einzelnen IDP, der weblate in SOCIAL_AUTH_SAML_ENABLED_IDPS genannt werden muss.
Die URL der SAML-XML-Metadaten lautet /accounts/metadata/saml/, die auch eine Entitäts-ID ist.
Die Anmelde-URL lautet /accounts/complete/saml/ (auch bekannt als ACS-URL).
Die folgenden Einstellungen werden automatisch ausgefüllt: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Beispielkonfiguration:

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

Sie können ein neues Schlüsselpaar wie folgt generieren:

openssl req -newkey rsa:4096 -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.key

Die Standardkonfiguration extrahiert Benutzerdetails aus den folgenden Attributen; konfigurieren Sie Ihre IdP so, dass sie diese bereitstellt:

Attribut	SAML-URI-Referenz
Vollständiger Name	`urn:oid:2.5.4.3`
Vorname	`urn:oid:2.5.4.42`
Nachname	`urn:oid:2.5.4.4`
E-Mail-Adresse	`urn:oid:0.9.2342.19200300.100.1.3`
Benutzername	`urn:oid:0.9.2342.19200300.100.1.1`

Bei der Konfiguration von Weblate SP in Ihrem IdP wird empfohlen, das persistente Name ID format auszuwählen.

Hinweis

Bei einigen Identitätsanbietern (wie beispielsweise Microsoft Entra ID mit Multi-Faktor-Authentifizierung) muss das standardmäßige requestedAuthnContext in der SAML-Sicherheitskonfiguration deaktiviert werden:

SOCIAL_AUTH_SAML_SECURITY_CONFIG = {"requestedAuthnContext": False}

In Docker stattdessen WEBLATE_SAML_SECURITY_CONFIG setzen.

Hinweis

Das obige Beispiel und das Docker-Image definieren eine IdP namens weblate. Möglicherweise müssen Sie diese Zeichenkette als Relay in Ihrem IdP konfigurieren.

Bemerkung

Die Authentifizierung von Weblate beruht auf dem Parameter RelayState, der an den Authentifizierungsprozess übergeben wird. Dieser muss bei einigen Identitätsanbietern konfiguriert werden:

So senden Sie einen benutzerdefinierten RelayState mit Okta

Siehe auch

LDAP-Authentifizierung¶

Die LDAP-Authentifizierung lässt sich am besten mit dem Paket django-auth-ldap erreichen. Sie können es mit den üblichen Mitteln installieren:

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

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

Hinweis

Dieses Paket ist im Docker-Container enthalten, siehe Installation über Docker.

Bemerkung

Es gibt einige Inkompatibilitäten im Python-LDAP-3.1.0-Modul, die Sie möglicherweise daran hindern, diese Version zu verwenden. Wenn Sie den Fehler AttributeError: ‚module‘ object has no attribute ‚_trace_level‘ erhalten, könnte ein Downgrade von python-ldap auf 3.0.0 helfen.

Sobald Sie das Paket installiert haben, können Sie es mit der Django-Authentifizierung verbinden:

# 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",
}
# Optional: route "Forgot your password?" to your LDAP self-service page
PASSWORD_RESET_URL = "https://id.example.net/password-reset/"


# Hide the registration form
REGISTRATION_OPEN = False

Bemerkung

Sie sollten 'social_core.backends.email.EmailAuth' aus der AUTHENTICATION_BACKENDS-Einstellung entfernen, da Benutzer sonst ihr Passwort in Weblate setzen und sich damit authentifizieren können. Das Beibehalten von 'weblate.accounts.auth.WeblateUserBackend' wird immer noch benötigt, um Berechtigungen zu vergeben und anonyme Benutzer zu ermöglichen. Außerdem können Sie sich mit einem lokalen Administratorkonto anmelden, wenn Sie es erstellt haben (z B. mit createadmin).

Bindungspasswort verwenden¶

Wenn Sie keine direkte Bindung für die Authentifizierung verwenden können, müssen Sie die Suche verwenden, und einen Benutzer zur Bindung für die Suche angeben. Zum Beispiel:

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

Integration von Active Directory¶

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

Siehe auch

CAS-Authentifizierung¶

Die CAS-Authentifizierung kann mit einem Paket wie Django CAS NG erreicht werden.

Schritt eins ist die Offenlegung des E-Mail-Feldes des Benutzers über CAS. Dies muss auf dem CAS-Server selbst konfiguriert werden und setzt voraus, dass Sie mindestens CAS v2 verwenden, da CAS v1 Attribute überhaupt nicht unterstützt.

Der zweite Schritt ist die Aktualisierung von Weblate zur Verwendung Ihres CAS-Servers und Ihrer Attribute.

Um Django CAS NG zu installieren:

uv pip install django-cas-ng

Sobald Sie das Paket installiert haben, können Sie es an das Django-Authentifizierungssystem anbinden, indem Sie die Datei settings.py ändern:

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

Schließlich kann ein Signal verwendet werden, um das E-Mail-Feld dem Benutzerobjekt zuzuordnen. Damit dies funktioniert, müssen Sie das Signal aus dem Paket django-cas-ng importieren und Ihren Code mit diesem Signal verbinden. Dies in der Einstellungsdatei zu tun, kann zu Problemen führen, daher ist es empfehlenswert, dies zu tun:

In der Methode django.apps.AppConfig.ready() Ihrer App-Konfiguration
In der Datei urls.py des Projekts (wenn keine Modelle vorhanden sind)

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

Django-Authentifizierung von Drittanbietern konfigurieren¶

Generell sollte jedes Django-Authentifizierungs-Plugin mit Weblate funktionieren. Folgen Sie einfach den Anweisungen für das Plugin und denken Sie daran, das Weblate-Benutzer-Backend installiert zu lassen.

Siehe auch

LDAP-Authentifizierung
CAS-Authentifizierung

Typischerweise besteht die Installation aus dem Hinzufügen eines Authentifizierungs-Backends zu AUTHENTICATION_BACKENDS und der Installation einer Authentifizierungs-App (falls es eine gibt) in INSTALLED_APPS:

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

INSTALLED_APPS += (
    # Install authentication app here
)

Zwei-Faktor-Authentifizierung¶

Added in version 5.7.

Hinweis

Die Zwei-Faktor-Authentifizierung fügt Ihrem Benutzerkonto eine weitere Sicherheitsebene hinzu, indem sie mehr als nur ein Passwort für die Anmeldung verlangt.

Weblate unterstützt die folgenden Zweitfaktoren:

Sicherheitsschlüssel (WebAuthn)

Es werden sowohl Passkeys als auch Sicherheitsschlüssel unterstützt.

Passkeys bestätigen die Identität durch Berührung, Gesichtserkennung, ein Gerätepasswort oder eine PIN, da sie eine Benutzerverifizierung beinhalten.

Bei den Sicherheitsschlüsseln handelt es sich um WebAuthn-Zugangsdaten, die nur als zweiter Faktor der Authentifizierung verwendet werden können und die nur die Anwesenheit des Benutzers bestätigen.

Wenn Sie sich auf einem neuen Computer oder in einem anderen Browser anmelden, ist Ihr Passkey möglicherweise nicht verfügbar. Verwenden Sie ein Gerät, auf dem der Passkey verfügbar ist, oder verbinden Sie Ihren registrierten Sicherheitsschlüssel. Ein Verifizierungsfehler kann bedeuten, dass die Anfrage abgelaufen ist, abgebrochen wurde oder dass die Zugangsdaten nicht verfügbar sind; die genaue Ursache wird dabei nicht angegeben.

Sie können auf der Anmeldeseite auch eine andere konfigurierte Verifizierungsmethode auswählen, z. B. Wiederherstellungscodes verwenden. Wenn Sie keine der konfigurierten Methoden verwenden können, wenden Sie sich bitte an den Website-Administrator, um Hilfe zu erhalten.

Authentifizierungs-Apps (TOTP)

Authentifizierungs-Apps und Browser-Erweiterungen wie Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator usw. generieren zeitbasierte Einmalpasswörter, die als zweiter Faktor zum Verifizieren der Identität verwendet werden, wenn Sie bei der Anmeldung dazu aufgefordert werden.

Registration becomes active only after you verify a code from the app. Complete registration within 10 minutes of confirming your sign-in method; otherwise confirm it again and use the new QR code. Each registration can be completed only once. After registering, wait for the next code before using the app to sign in.

Only one registration can be pending per account. Confirming your sign-in method in another browser session invalidates the pending QR code and starts a new registration.

Wenn Sie mehr als eine registrierte Authentifizierungs-App haben, wählen Sie die gerade verwendete App aus, wenn Sie deren Code bei der Anmeldung eingeben.

Wiederherstellungscodes

Wiederherstellungscodes können verwendet werden, um auf Ihr Benutzerkonto zuzugreifen, wenn Sie den Zugriff auf Ihr Gerät verlieren und keine Codes für die Zwei-Faktor-Authentifizierungcodes erhalten können.

Bewahren Sie die Wiederherstellungscodes genauso sicher auf wie das Passwort. Wir empfehlen, sie mit einem Passwortmanager wie Bitwarden, 1Password, Authy oder Keeper zu speichern.

Jeder Benutzer kann dies in :Sicherheit konfigurieren und der zweite Faktor wird zusätzlich zur bestehenden Authentifizierungsmethode benötigt.

Before registering the first authenticator app or security key, confirm your existing sign-in method. Enter your current Weblate password if you have one. Accounts without a Weblate password must sign in again through an already connected authentication provider. If neither method is available, contact an administrator to recover access. Registering a new factor does not count as a recent second-factor verification for other sensitive actions, such as creating a project token; complete a separate second-factor challenge for those actions.

When two-factor authentication is configured, viewing the personal API key or changing sign-in methods and recovery credentials requires a second-factor verification from the last 10 minutes. Weblate prompts for verification again when that period has passed. Removing project members or tokens and deleting your account also require a recent second-factor verification. Account deletion still requires confirmation through a link sent to your e-mail address.

Dies kann für Benutzer auf Projekt- (siehe Erzwungene Zwei-Faktor-Authentifizierung) oder Teamebene erzwungen werden. Bei plattformweiten Bereitstellungen kann dies auch verwendet werden, um die Zwei-Faktor-Authentifizierung für alle Benutzer zu erzwingen, indem sie für das standardmäßige Benutzer-Team aktiviert wird, das neuen Benutzern durch automatische Teamzuweisungen automatisch zugewiesen wird.

Die Berechtigungen eines Teams mit erzwungener Zwei-Faktor-Authentifizierung werden nicht auf Benutzer angewendet, die diese nicht konfiguriert haben.

Authentifizierung¶

Benutzerregistrierung¶

Authentifizierungs-Backends¶

Teams von Identitätsanbietern¶

Soziale Authentifizierung¶

Authentifizierungsspeicher bereinigen¶

OpenID¶

GitHub¶

GitHub EE¶

Bitbucket¶

Google OAuth 2¶

Facebook OAuth 2¶

GitLab OAuth 2¶

Gitea OAuth 2¶

Microsoft Entra ID¶

Slack¶

Weblate OpenID Connect¶

Namen und Symbole für Authentifizierungsmethoden überschreiben¶

Passwort-Authentifizierung deaktivieren¶

Passwort-Authentifizierung¶

OpenID-Connect-Identitätsanbieter¶

SAML-Authentifizierung¶

LDAP-Authentifizierung¶

Bindungspasswort verwenden¶

Integration von Active Directory¶

CAS-Authentifizierung¶

Django-Authentifizierung von Drittanbietern konfigurieren¶

Zwei-Faktor-Authentifizierung¶