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 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¶
Die integrierte Lösung von Django wird für die Authentifizierung verwendet, einschließlich verschiedener sozialer Optionen, um dies zu tun. Wenn Sie sie verwenden, können Sie die Benutzerdatenbank anderer Django-basierter Projekte importieren (siehe Migration von Pootle).
Django kann zusätzlich so eingerichtet werden, dass es sich auch gegenüber anderen Mitteln authentifiziert.
Siehe auch
Authentifizierungseinstellungen beschreibt, wie man die Authentifizierung im offiziellen Docker-Image konfiguriert.
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-password-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
SAML-Authentifizierung¶
Added in version 4.1.1.
Bitte folgen Sie den Anweisungen von Python Social Auth für die Konfiguration. Bedeutende Unterschiede:
Weblate unterstützt einen einzelnen IDP, der
weblate
inSOCIAL_AUTH_SAML_ENABLED_IDPS
genannt werden muss.Die URL der SAML-XML-Metadaten lautet
/accounts/metadata/saml/
.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==",
"attr_name": "full_name",
"attr_username": "username",
"attr_email": "email",
}
}
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"
}
Die Standardkonfiguration extrahiert Benutzerdetails aus den folgenden Attributen; konfigurieren Sie Ihre IDP so, dass sie diese bereitstellt:
Attribut |
SAML-URI-Referenz |
---|---|
Vollständiger Name |
|
Vorname |
|
Nachname |
|
|
|
Benutzername |
|
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.
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",
}
# 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
).
Bindungs-Passwort verwenden¶
Wenn Sie keine direkte Bindung für die Authentifizierung verwenden können, müssen Sie die Suche verwenden und einen Benutzer für die 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-KonfigurationIn 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()
Siehe auch
Konfigurieren der Django-Authentifizierung von Drittanbietern¶
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
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.
- 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.
- 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 im Benutzerkonto konfigurieren und der zweite Faktor wird zusätzlich zur bestehenden Authentifizierungsmethode benötigt.
Dies kann für Benutzer auf Projekt- (siehe Erzwungene Zwei-Faktor-Authentifizierung) oder Team-Ebene erzwungen werden.
Die Berechtigungen eines Teams mit erzwungener Zwei-Faktor-Authentifizierung werden nicht auf Benutzer angewendet, die diese nicht konfiguriert haben.
Soziale Authentifizierung¶
Dank Welcome to Python Social Auth’s documentation! unterstützt Weblate die Authentifizierung über viele Dienste von Drittanbietern wie GitLab, Ubuntu, Fedora, etc.
Bitte lesen Sie die Dokumentation für allgemeine Konfigurationsanweisungen in Django Framework.
Bemerkung
Standardmäßig verlässt sich Weblate auf die Authentifizierungsdienste von Drittanbietern, um eine geprüfte E-Mail-Adresse bereitzustellen. Wenn einige der Dienste, die Sie verwenden möchten, dies nicht unterstützen, erzwingen Sie bitte die E-Mail-Validierung auf der Weblate-Seite, indem Sie FORCE_EMAIL_VALIDATION für sie konfigurieren. Zum Beispiel:
Siehe auch
Pipeline
Das Aktivieren einzelner Backends ist recht einfach: Sie müssen lediglich einen Eintrag in der Einstellung
AUTHENTICATION_BACKENDS
hinzufügen und eventuell die für eine bestimmte Authentifizierungsmethode benötigten Schlüssel hinzufügen. Bitte beachten Sie, dass einige Backends standardmäßig keine Benutzer-E-Mails zur Verfügung stellen. Sie müssen diese explizit anfordern, da Weblate sonst nicht in der Lage ist, die Beiträge der Benutzer richtig zuzuordnen.Hinweis
Die meisten der Authentifizierungs-Backends erfordern HTTPS. Sobald HTTPS in Ihrem Webserver aktiviert ist, konfigurieren Sie Weblate bitte mit
ENABLE_HTTPS
oder durchWEBLATE_ENABLE_HTTPS
im Docker-Container so, dass es korrekt gemeldet wird.Siehe auch
Python Social Auth Backend
OpenID-Authentifizierung¶
Für OpenID-basierte Dienste ist es normalerweise nur eine Frage der Aktivierung. Der folgende Abschnitt aktiviert die OpenID-Authentifizierung für OpenSUSE, Fedora und Ubuntu:
Siehe auch
OpenID
GitHub-Authentifizierung¶
Sie müssen eine OAuth-Anwendung auf GitHub registrieren und dann Weblate alle ihre Geheimnisse mitteilen:
GitHub sollte so konfiguriert sein, dass die Callback-URL
https://WEBLATE SERVER/accounts/complete/github/
lautet.Es gibt ähnliche Authentifizierungs-Backends für GitHub for Organizations und GitHub for Teams. Ihre Einstellungen heißen
SOCIAL_AUTH_GITHUB_ORG_*
undSOCIAL_AUTH_GITHUB_TEAM_*
, und sie erfordern zusätzliche Einstellungen des BereichsSOCIAL_AUTH_GITHUB_ORG_NAME
oderSOCIAL_AUTH_GITHUB_TEAM_ID
. Ihre Callback-URLs lautenhttps://WEBLATE SERVER/accounts/complete/github-org/
undhttps://WEBLATE SERVER/accounts/complete/github-teams/
.Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
GitHub
GitHub-EE-Authentifizierung¶
Sie müssen eine OAuth-Anwendung auf GitHub EE registrieren und dann Weblate alle ihre Geheimnisse mitteilen:
GitHub sollte so konfiguriert sein, dass die Callback-URL
https://WEBLATE SERVER/accounts/complete/github-enterprise/
lautet.Statt der GitHub-OAuth-App kann auch die GitHub-App verwendet werden. Mit der GitHub-App können Berechtigungen auf Repositorys, Organisations- und/oder Benutzerebene erteilt werden. Wenn Sie sich für die Verwendung der GitHub-App entscheiden, müssen Sie die Berechtigung Access: Read-only für Benutzer – <E-Mail-Adressen> und Organisation – <Mitglieder> aktivieren.
Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
GitHub Enterprise
Bitbucket-Authentifizierung¶
Sie müssen eine Anwendung bei Bitbucket registrieren und dann Weblate alle ihre Geheimnisse mitteilen:
Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
Bitbucket
Google OAuth 2¶
Um Google OAuth 2 zu verwenden, müssen Sie eine Anwendung unter <https://console.developers.google.com/> registrieren und die Google+-API aktivieren.
Die Weiterleitungs-URL lautet
https://WEBLATE SERVER/accounts/complete/google-oauth2/
.Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
Google
Facebook OAuth 2¶
Wie bei „OAuth 2“-Diensten üblich, müssen Sie Ihre Anwendung bei Facebook registrieren. Sobald dies geschehen ist, können Sie Weblate einrichten, um es zu nutzen:
Die Weiterleitungs-URL lautet
https://WEBLATE SERVER/accounts/complete/facebook/
.Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
Facebook
GitLab OAuth 2¶
Um GitLab OAuth 2 zu verwenden, müssen Sie eine Anwendung unter <https://gitlab.com/profile/applications> registrieren.
Die Weiterleitungs-URL lautet
https://WEBLATE SERVER/accounts/complete/gitlab/
und stellen Sie sicher, dass Sie den Bereich read_user markieren.Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
GitLab
Gitea OAuth 2¶
Um GitLab OAuth 2 zu verwenden, müssen Sie eine Anwendung unter
https://GITEA SERVER/user/settings/applications
registrieren.Die Weiterleitungs-URL lautet
https://WEBLATE SERVER/accounts/complete/gitea/
.Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Bemerkung
Die obige Konfiguration funktioniert auch mit Forgejo; für ein Beispiel der produktiven Bereitstellung mit Forgejo siehe Codeberg Translate.
Siehe auch
Gitea
Microsoft Azure Active Directory¶
Weblate kann so konfiguriert werden, dass allgemeine oder spezifische Mandanten für die Authentifizierung verwendet werden.
Die Weiterleitungs-URL lautet
https://WEBLATE SERVER/accounts/complete/azuread-oauth2/
für allgemeine undhttps://WEBLATE SERVER/accounts/complete/azuread-tenant-oauth2/
für mandantenspezifische Authentifizierung.Sie benötigen Folgendes:
Die Anwendungs-(Client-)ID kann von der Anwendungsseite abgerufen werden. Die Objekt-ID wird in Weblate nicht verwendet.
Die Verzeichnis-(Mandanten-)ID wird für eine mandantenabhängige Authentifizierung benötigt, was in der Regel erwünscht ist.
Der Geheimniswert wird angezeigt, sobald Sie ein Geheimnis für eine Anwendung erzeugen. Die Geheimnis-ID wird in Weblate nicht verwendet.
Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
Microsoft Azure Active Directory
Slack¶
Um Slack OAuth 2 zu verwenden, müssen Sie eine Anwendung unter <https://api.slack.com/apps> registrieren.
Die Weiterleitungs-URL lautet
https://WEBLATE SERVER/accounts/complete/slack/
.Bemerkung
Die von Weblate während der Authentifizierung bereitgestellte Callback-URL enthält die konfigurierte Domain. Falls Sie Fehlermeldungen über eine nicht übereinstimmende URL erhalten, sollten Sie dies beheben, siehe Seitendomain richtig einstellen.
Siehe auch
Slack
Überschreiben von Namen und Symbolen für Authentifizierungsmethoden¶
Sie können den Anzeigenamen und das Symbol der Authentifizierungsmethode überschreiben, indem Sie die Einstellungen
SOCIAL_AUTH_<NAME>_IMAGE
undSOCIAL_AUTH_<NAME>_TITLE
verwenden. Zum Beispiel würde das Überschreiben der Benennung für Auth0 wie folgt aussehen:Passwort-Authentifizierung deaktivieren¶
E-Mail- und Passwort-Authentifizierung können ausgeschaltet werden, indem man
social_core.backends.email.EmailAuth
ausAUTHENTICATION_BACKENDS
entfernt. Behalten Sieweblate.accounts.auth.WeblateUserBackend
dort, es wird für die Kernfunktionalität von Weblate benötigt.Durch die Deaktivierung der E-Mail-Authentifizierung werden alle E-Mail-bezogenen Funktionen deaktiviert, z. B. die Benutzereinladung oder die Funktion zum Zurücksetzen des Passworts.
Tipp
Sie können weiterhin die Passwortauthentifizierung für die Adminoberfläche verwenden, für Benutzer, die Sie dort manuell erstellen. Navigieren Sie einfach zu
/admin/login/
.Zum Beispiel kann die Authentifizierung nur mit dem openSUSE-Open-ID-Anbieter wie folgt erreicht werden: