Autentifikácia¶

Registrácia používateľa¶

Predvolené nastavenie pre Weblate je používať python-social-auth, formulár na webovej stránke na spracovanie registrácie nových používateľov. Po potvrdení ich e-mailu môže nový používateľ prispievať alebo sa autentifikovať pomocou jednej zo služieb tretích strán.

Registráciu nových používateľov môžete tiež vypnúť pomocou REGISTRATION_OPEN.

Pokusu o autentifikáciu podliehajú Obmedzovanie rýchlosti.

Backendy autentifikácie¶

Weblate sa spolieha na Django pre autentifikáciu. To zahŕňa vstavanú autentifikáciu založenú na hesle, sociálnu autentifikáciu a backendy autentifikácie tretích strán pre Django.

Použitie vstavanej autentifikácie Django znamená, že môžete importovať databázu používateľov z iných projektov založených na Django (pozri Migrácia z Pootle).

Viď aj

Nastavenia autentifikácie popisuje, ako konfigurovať autentifikáciu v oficiálnom obraze Docker.

Teams from identity providers¶

Added in version 2026.10.1.

Weblate can synchronize selected teams from external group memberships or application roles during social authentication. The default native and Docker pipelines include synchronization after authentication checks and two-factor authentication. Extraction and assignment are disabled until configured. If you use a custom authentication pipeline, place social_core.pipeline.user.sync_groups after all authentication checks, including weblate.legal.pipeline.tos_confirm when terms acceptance is enabled.

Map external identifiers to lists of existing Weblate team IDs. Find team IDs in the administration interface URL or the teams REST API. Names can repeat across project and workspace scopes, so they are not used as mapping targets.

For Microsoft Entra ID, prefer application roles:

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

Configure the provider to issue these roles. Group identifiers can instead be selected with GROUPS_KEY = "groups". Group overage causes authentication to fail; Weblate does not retrieve memberships from Microsoft Graph. Restrict the trusted tenant and issuer before granting permissions, especially when using a common Azure endpoint.

For generic OpenID Connect or Keycloak, configure a literal claim name:

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

For GitLab, explicitly enable membership retrieval:

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

Enabling retrieval automatically requests read_api unless read_api or api is already requested. Enable the corresponding permission in the GitLab OAuth application settings alongside read_user.

GitLab uses full group paths by default. Use stable numeric group IDs instead when paths might change or be reused:

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

For SAML, add the group attribute and mapping to each existing entry in SOCIAL_AUTH_SAML_ENABLED_IDPS:

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

All targets in a mapping become provider-managed teams. Authentication adds desired memberships and removes obsolete managed memberships. Unrelated teams and existing membership language restrictions are preserved. Changes are recorded in the audit log. Manual membership in a managed team is subject to replacement at the next authentication. A team may be managed by only one configured provider or SAML IdP; conflicting mappings and nonexistent teams cause errors before memberships change. No teams are created automatically.

A missing configured claim fails authentication. When a provider omits claims for users without assignments, explicitly enable its SOCIAL_AUTH_<BACKEND>_GROUPS_MISSING_AS_EMPTY setting. SAML uses groups_missing_as_empty in the IdP entry. An empty membership list removes all provider-managed memberships. An empty GROUPS_MAP disables assignment.

Login restrictions are independent of assignment. Configure SOCIAL_AUTH_<BACKEND>_ALLOW_GROUPS to require membership in any listed external group or role. Unknown identifiers grant nothing, but do not reject login unless an allow list is configured. Existing CAS allow lists require no new settings or pipeline entries.

Synchronization applies to login, registration, and authentication-method linking. Password reset and account removal do not synchronize teams. Updates occur only during authentication; this does not deactivate accounts or revoke access in the background. Synchronization does not store external membership snapshots.

In Docker installations, use Konfigurácia nad rámec premenných prostredia to supply these Python settings; there are no dedicated environment variables for team mappings.

Viď aj

External groups

Autentifikácia heslom¶

Predvolený settings.py prichádza s rozumnou sadou AUTH_PASSWORD_VALIDATORS, ktorá zabezpečuje, že slabé heslá nie sú povolené. Toto nastavenie môžete prispôsobiť tak, aby zodpovedalo vašej politike hesiel.

Okrem toho môžete nainštalovať aj django-zxcvbn-password-validator, ktorý poskytuje celkom realistické odhady obtiažnosti hesla a umožňuje zamietnuť heslá pod určitým prahom.

Viď aj

Autentifikácia SAML¶

Added in version 4.1.1.

Zmenené vo verzii 5.12: Závislosti pre autentifikáciu SAML už nie sú súčasťou predvolených extra balíčkov all. Musíte zahrnúť saml pri inštalácii balíka Weblate pomocou pip (uv pip install Weblate[all,saml]).

Prosím, dodržte pokyny Python Social Auth pre konfiguráciu. Pozoruhodné rozdiely:

Weblate podporuje jediný IDP, ktorý sa musí volať weblate v SOCIAL_AUTH_SAML_ENABLED_IDPS.
URL metadát SAML XML je /accounts/metadata/saml/, čo je tiež ID entity.
URL prihlásenia je /accounts/complete/saml/ (známe aj ako ACS URL).
Nasledujúce nastavenia sa vyplnia automaticky: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Príklad konfigurácie:

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

Nový pár kľúčov môžete vygenerovať pomocou:

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

Predvolená konfigurácia extrahuje podrobnosti o používateľovi z nasledujúcich atribútov, nakonfigurujte svoj IdP, aby ich poskytoval:

Atribút	Referencia SAML URI
Celé meno	`urn:oid:2.5.4.3`
Meno	`urn:oid:2.5.4.42`
Priezvisko	`urn:oid:2.5.4.4`
E-mail	`urn:oid:0.9.2342.19200300.100.1.3`
Používateľské meno	`urn:oid:0.9.2342.19200300.100.1.1`

Pri konfigurácii Weblate SP vo vašom IdP sa odporúča zvoliť trvalý Formát ID mena.

Rada

Niektorí poskytovatelia identity (ako napríklad Microsoft Entra ID s viacfaktorovou autentifikáciou) vyžadujú vypnutie predvoleného requestedAuthnContext v bezpečnostnej konfigurácii SAML:

SOCIAL_AUTH_SAML_SECURITY_CONFIG = {"requestedAuthnContext": False}

V Dockeri nastavte namiesto toho WEBLATE_SAML_SECURITY_CONFIG.

Rada

Vyššie uvedený príklad a obraz Docker definujú IdP s názvom weblate. Tento reťazec možno budete musieť nakonfigurovať ako Relay vo vašom IdP.

Poznámka

Autentifikácia Weblate sa spolieha na parameter RelayState, ktorý sa prenáša počas procesu autentifikácie. Toto je potrebné nakonfigurovať s niektorými poskytovateľmi identít:

Ako odoslať vlastný RelayState s Okta

Viď aj

Autentifikácia LDAP¶

Autentifikáciu LDAP je najlepšie dosiahnuť pomocou balíka django-auth-ldap. Môžete ho nainštalovať obvyklými spôsobmi:

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

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

Rada

Tento balík je zahrnutý v kontajneri Docker, pozri Inštalácia pomocou Dockeru.

Poznámka

V module Python LDAP 3.1.0 existujú určité nekompatibility, ktoré vám môžu brániť v používaní tejto verzie. Ak dostanete chybu AttributeError: ‚module‘ object has no attribute ‚_trace_level‘, môže pomôcť downgrade python-ldap na 3.0.0.

Keď máte balík nainštalovaný, môžete ho pripojiť k autentifikácii Django:

# 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

Poznámka

Mali by ste odstrániť 'social_core.backends.email.EmailAuth' z nastavenia AUTHENTICATION_BACKENDS, inak budú používatelia môcť nastaviť svoje heslo vo Weblate a autentifikovať sa pomocou neho. Ponechanie 'weblate.accounts.auth.WeblateUserBackend' je stále potrebné na zabezpečenie oprávnení a uľahčenie práce anonymným používateľom. Umožní vám tiež prihlásiť sa pomocou lokálneho administrátorského účtu, ak ste ho vytvorili (napr. pomocou createadmin).

Použitie bind hesla¶

Ak nemôžete použiť priame bind pre autentifikáciu, budete musieť použiť vyhľadávanie a poskytnúť používateľa na bind pre vyhľadávanie. Napríklad:

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

Integrácia 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

Viď aj

Autentifikácia CAS¶

Autentifikáciu CAS je možné dosiahnuť pomocou balíka, ako je Django CAS NG.

Prvým krokom je zverejnenie poľa e-mailu používateľa prostredníctvom CAS. Toto je potrebné nakonfigurovať na samotnom serveri CAS a vyžaduje, aby ste používali aspoň CAS v2, pretože CAS v1 vôbec nepodporuje atribúty.

Druhým krokom je aktualizácia Weblate na používanie vášho servera CAS a atribútov.

Na inštaláciu Django CAS NG:

uv pip install django-cas-ng

Keď máte balík nainštalovaný, môžete ho pripojiť k systému autentifikácie Django úpravou súboru 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")

Nakoniec, na mapovanie poľa e-mailu na objekt používateľa je možné použiť signál. Aby to fungovalo, musíte importovať signál z balíka django-cas-ng a pripojiť svoj kód k tomuto signálu. Robenie toho v súbore nastavení môže spôsobiť problémy, preto sa odporúča umiestniť ho:

Do metódy django.apps.AppConfig.ready() konfigurácie vašej aplikácie
Do súboru urls.py projektu (keď neexistujú žiadne modely)

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

Konfigurácia autentifikácie Django tretích strán¶

Všeobecne by mal každý plugin autentifikácie Django fungovať s Weblate. Stačí dodržiavať pokyny pre plugin, nezabudnite však ponechať nainštalovaný backend používateľa Weblate.

Viď aj

Autentifikácia LDAP
Autentifikácia CAS

Inštalácia zvyčajne pozostáva z pridania backendu autentifikácie do AUTHENTICATION_BACKENDS a inštalácie aplikácie autentifikácie (ak nejaká existuje) do INSTALLED_APPS:

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

INSTALLED_APPS += (
    # Install authentication app here
)

Dvojfaktorová autentifikácia¶

Added in version 5.7.

Rada

Dvojfaktorová autentifikácia pridáva ďalšiu vrstvu zabezpečenia vášmu účtu tým, že vyžaduje viac než len heslo na prihlásenie.

Weblate podporuje nasledujúce druhé faktory:

Bezpečnostné kľúče (WebAuthn)

Podporované sú Passkeys aj bezpečnostné kľúče.

Passkeys overujú vašu identitu pomocou dotyku, rozpoznávania tváre, hesla zariadenia alebo PINu, pretože zahŕňajú overenie používateľa.

Bezpečnostné kľúče sú poverenia WebAuthn, ktoré sa dajú použiť iba ako druhý faktor autentifikácie, a tieto iba overujú prítomnosť používateľa.

Pri prihlasovaní na novom počítači alebo v inom prehliadači môže byť váš passkey nedostupný. Použite zariadenie, kde je passkey dostupný, alebo pripojte svoj registrovaný bezpečnostný kľúč. Chyba overovania môže znamenať, že požiadavka vypršala časovým limitom, bola zrušená alebo že poverenie nie je dostupné; neidentifikuje presnú príčinu.

Na prihlasovacej stránke môžete tiež vybrať inú nakonfigurovanú metódu overovania, napríklad Použiť obnovovacie kódy. Ak nemôžete použiť žiadnu nakonfigurovanú metódu, kontaktujte administrátora stránky pre pomoc.

Autentifikačné aplikácie (TOTP)

Autentifikačné aplikácie a rozšírenia prehliadača, ako sú Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator atď., generujú jednorazové heslá založené na čase, ktoré sa používajú ako druhý faktor na overenie vašej identity, keď ste vyzvaní počas prihlasovania.

Registrácia sa stane aktívnou až po overení kódu z aplikácie. Dokončite registráciu do 24 hodín; inak začnite znova s novým QR kódom. Každá registrácia sa dá dokončiť iba raz. Po registrácii počkajte na ďalší kód, skôr než použijete aplikáciu na prihlásenie.

Na jeden účet môže byť čakajúca iba jedna registrácia. Otvorenie registrácie v inej relácii prehliadača zobrazuje rovnaký QR kód, kým sa registrácia nedokončí alebo nevyprší.

If you have more than one registered authenticator app, select the app you are using when entering its code during sign-in.

Obnovovacie kódy

Obnovovacie kódy je možné použiť na prístup k vášmu účtu, ak stratíte prístup k svojmu zariadeniu a nemôžete prijímať kódy dvojfactorovej autentifikácie.

Svoje obnovovacie kódy uchovávajte rovnako bezpečne ako svoje heslo. Odporúčame ich ukladať pomocou správcu hesiel, ako je Bitwarden, 1Password, Authy alebo Keeper.

Každý používateľ si to môže nakonfigurovať v Účet a druhý faktor bude vyžadovaný na prihlásenie navyše k existujúcej metóde autentifikácie.

Toto je možné vynútiť pre používateľov na úrovni projektu (pozri Vynútená dvojfaktorová autentifikácia) alebo tímu. Pri nasadeniach pre celú stránku sa to dá tiež použiť na vynútenie dvojfaktorovej autentifikácie pre všetkých používateľov povolením v predvolenom tíme Používatelia, ktorý je automaticky priradený novým používateľom pomocou automatického priraďovania tímov.

Oprávnenia tímu s vynútenou dvojfaktorovou autentifikáciou sa neuplatnia na používateľov, ktorí ju nemajú nakonfigurovanú.

Autentifikácia¶

Registrácia používateľa¶

Backendy autentifikácie¶

Teams from identity providers¶

Sociálna autentifikácia¶

Authentication storage cleanup¶

Autentifikácia OpenID¶

Autentifikácia GitHub¶

Autentifikácia GitHub EE¶

Autentifikácia Bitbucket¶

Google OAuth 2¶

Facebook OAuth 2¶

GitLab OAuth 2¶

Gitea OAuth 2¶

Microsoft Entra ID¶

Slack¶

Prepísanie názvov a ikon metód autentifikácie¶

Vypnutie autentifikácie heslom¶

Autentifikácia heslom¶

Autentifikácia SAML¶

Autentifikácia LDAP¶

Použitie bind hesla¶

Integrácia Active Directory¶

Autentifikácia CAS¶

Konfigurácia autentifikácie Django tretích strán¶

Dvojfaktorová autentifikácia¶