Hitelesítés¶

Felhasználói regisztráció¶

A Weblate alapértelmezett beállítása a python-social-auth használata, ami egy űrlapot biztosít az új felhasználók regisztrációjához az oldalon. Az e-mail cím megerősítése után az új felhasználó már hozzájárulhat vagy bejelentkezhet valamelyik harmadik féltől származó szolgáltatáson keresztül.

A REGISTRATION_OPEN beállítással a regisztráció lehetősége kikapcsolható.

A hitelesítési kísérletek a sebességkorlátozás hatálya alá esnek.

Hitelesítési háttérrendszerek¶

A Weblate a Django hitelesítési rendszerére támaszkodik. Ez magában foglalja a beépített jelszóalapú hitelesítést, a közösségi hitelesítést, valamint a Django által támogatott külső hitelesítési háttereket.

A Django beépített hitelesítési rendszerének használata lehetővé teszi más, Django-alapú projektek felhasználói adatbázisának importálását is (lásd: Átállás Pootle rendszerről).

Lásd még

A hivatalos Docker-kép hitelesítési beállításairól lásd: Hitelesítési beállítások.

Jelszóval történő hitelesítés¶

Az alapértelmezett settings.py egy biztonságos AUTH_PASSWORD_VALIDATORS beállítással érkezik, ami biztosítja, hogy gyenge jelszavakat ne lehessen használni. Ez a beállítás igény szerint testreszabható a saját jelszóházirendhez.

Ezen felül telepíthető a django-zxcvbn-password-validator csomag is, amely valósághű becslést ad a jelszavak erősségéről, és lehetővé teszi a túl gyenge jelszavak automatikus elutasítását.

Lásd még

SAML-hitelesítés¶

Added in version 4.1.1.

A 5.12 verzióban változott: A SAML-alapú hitelesítéshez szükséges függőségek már nem részei az alapértelmezett all kiegészítőnek. A Weblate csomag telepítésekor külön fel kell venni a saml kiegészítőt is a pip használatakor (uv pip install Weblate[all,saml]).

Kövesse a Python Social Auth dokumentációját a konfiguráláshoz. A leíráshoz képest néhány fontos eltérés:

A Weblate egyetlen IDP-t támogat, amelynek neve weblate kell legyen a SOCIAL_AUTH_SAML_ENABLED_IDPS beállításban.
The SAML XML metadata URL is /accounts/metadata/saml/, which is also an entity ID.
The sign-in URL is /accounts/complete/saml/ (also known as ACS URL).
A következő beállítások automatikusan kitöltésre kerülnek: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Példa konfiguráció:

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

You can generate a new pair of keys using:

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

The default configuration extracts user details from following attributes, configure your IdP to provide them:

Attribútum	SAML URI hivatkozás
Teljes név	`urn:oid:2.5.4.3`
Keresztnév	`urn:oid:2.5.4.42`
Vezetéknév	`urn:oid:2.5.4.4`
E-mail	`urn:oid:0.9.2342.19200300.100.1.3`
Felhasználónév	`urn:oid:0.9.2342.19200300.100.1.1`

When configuring Weblate SP in your IdP, it is recommended to choose persistent Name ID format.

Tipp

The example above and the Docker image define an IdP called weblate. You might need to configure this string as Relay in your IdP.

Megjegyzés

Weblate authentication relies on the RelayState parameter to be passed through the authentication process. This needs to be configured with some identity providers:

How to Send a Custom RelayState with Okta

Lásd még

LDAP-hitelesítés¶

Az LDAP-hitelesítés legegyszerűbben a django-auth-ldap csomaggal valósítható meg. A telepítése a szokásos módon történhet:

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

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

Tipp

Ez a csomag a Docker-képen alapból benne van, lásd: Telepítés Docker használatával.

Megjegyzés

A Python LDAP 3.1.0 modulban néhány inkompatibilitás található, ami megakadályozhatja a működést. Ha a következő hibát tapasztalja: AttributeError: «module» object has no attribute «_trace_level», akkor a python-ldap 3.0.0 verzióra való visszalépés megoldhatja a problémát.

Miután telepítette a csomagot, a Django hitelesítéséhez is hozzákapcsolhatja:

# 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

Megjegyzés

Érdemes eltávolítani a 'social_core.backends.email.EmailAuth' bejegyzést az AUTHENTICATION_BACKENDS beállításból, különben a felhasználók saját jelszót állíthatnak be a Weblate-ben, és azzal is be tudnak jelentkezni. Ugyanakkor a 'weblate.accounts.auth.WeblateUserBackend' bejegyzést szükséges megtartani, mivel ez biztosítja a jogosultságok és az anonim felhasználók kezelését. Emellett lehetőséget ad a helyi adminisztrátori fiókkal történő bejelentkezésre is, amennyiben ilyen létre lett hozva (például a createadmin használatával).

Bind jelszó használata¶

Amennyiben a közvetlen bind nem alkalmazható hitelesítéshez, keresést kell használnia, és ehhez egy olyan felhasználót kell megadnia, amellyel a keresést végrehajtja. Például:

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 integráció¶

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

Lásd még

CAS-hitelesítés¶

A CAS-hitelesítés megvalósítható például a Django CAS NG csomag segítségével.

Az első lépés a felhasználó e-mail mezőjének megosztása a CAS-on keresztül. Ezt a CAS szerveren kell beállítani, és legalább a CAS 2-es verzióját kell használnia, mivel a CAS 1 nem támogat attribútumokat.

A második lépés, hogy a Weblate-et frissítse úgy, hogy a saját CAS szerverét és annak attribútumait használja.

A Django CAS NG telepítése:

uv pip install django-cas-ng

Miután telepítette a csomagot, csatlakoztathatja a Django hitelesítési rendszeréhez a settings.py fájl módosításával:

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

Végül jeleket (signalt) használhat az e-mail mező felhasználói objektumhoz rendeléséhez. Ehhez importálnia kell a jelet a django-cas-ng csomagból, és összekapcsolni vele a saját kódját. Ezt a beállítási fájlban elvégezni problémát okozhat, ezért ajánlott az alábbi helyek egyikére tenni:

Az alkalmazás konfigurációjának django.apps.AppConfig.ready() metódusában elhelyezni,
A projekt urls.py fájljában (ha nem léteznek modellek)

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

Harmadik féltől származó Django hitelesítések beállítása¶

Általánosságban bármelyik Django-hitelesítési beépülő (plugin) működik a Weblate-tel. Kövesse a beépülő dokumentációját, és ügyeljen rá, hogy a Weblate felhasználói háttérmodul megmaradjon.

Lásd még

LDAP-hitelesítés
CAS-hitelesítés

A telepítés jellemzően abból áll, hogy egy új hitelesítési modult (backend) ad hozzá az AUTHENTICATION_BACKENDS beállításhoz, valamint az esetlegesen szükséges hitelesítési alkalmazást az INSTALLED_APPS listához:

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

INSTALLED_APPS += (
    # Install authentication app here
)

Kétlépcsős hitelesítés¶

Added in version 5.7.

Tipp

A kétlépcsős hitelesítés további biztonsági réteget ad a fiókjához azáltal, hogy a bejelentkezéshez nemcsak jelszót, hanem egyéb hitelesítést is megkövetel.

A Weblate az alábbi második hitelesítési tényezőket támogatja:

Biztonsági kulcsok (WebAuthn)

Támogatott a Passkey és a biztonsági kulcs is.

A Passkey érintés, arcfelismerés, eszközjelszó vagy PIN-kód segítségével azonosítja a felhasználót, mivel beépített felhasználóellenőrzést tartalmaz.

A biztonsági kulcs olyan WebAuthn hitelesítő adat, amelyek csak második azonosítási faktorként használható, és csak a felhasználó jelenlétét ellenőrzik.

Hitelesítő alkalmazások (TOTP)

A hitelesítő alkalmazások és böngészőbővítmények, mint például az Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator stb., időalapú egyszer használatos jelszavakat generálnak, amelyeket második tényezőként használnak az azonosítás megerősítésére a bejelentkezéskor.

Helyreállítási kódok

A helyreállítási kódok lehetővé teszik a fiókhoz való hozzáférést akkor is, ha elveszíti az eszközét, és nem tud kétlépcsős hitelesítési kódot fogadni.

A helyreállítási kódokat ugyanúgy biztonságban kell tartani, mint a jelszavakat. Ajánlott jelszókezelőben tárolni őket, például a Bitwarden, 1Password, Authy vagy Keeper alkalmazásokban.

Minden felhasználó saját maga is beállíthatja ezt a Fiók alatt, és ezután a bejelentkezéshez a meglévő hitelesítési mód mellett a második tényező megadása is szükséges lesz.

This can be enforced for users at the project (see Kétlépcsős azonosítás kényszerítése) or team level. In site-wide deployments, this can also be used to enforce two-factor authentication for all users by enabling it on the default Users team, which is assigned automatically to new users by automatic team assignment.

Azoknál a felhasználóknál, akiknél nincs beállítva kétlépcsős hitelesítés, a csapat jogosultságai nem lesznek érvényesek.

Hitelesítés¶

Felhasználói regisztráció¶

Hitelesítési háttérrendszerek¶

Közösségi hitelesítés¶

OpenID hitelesítés¶

GitHub hitelesítés¶

GitHub EE hitelesítés¶

Bitbucket hitelesítés¶

Google OAuth 2¶

Facebook OAuth 2¶

GitLab OAuth 2¶

Gitea OAuth 2¶

Microsoft Entra ID¶

Slack¶

Hitelesítési módszerek neveinek és ikonjainak felülírása¶

Jelszavas hitelesítés kikapcsolása¶

Jelszóval történő hitelesítés¶

SAML-hitelesítés¶

LDAP-hitelesítés¶

Bind jelszó használata¶

Active Directory integráció¶

CAS-hitelesítés¶

Harmadik féltől származó Django hitelesítések beállítása¶

Kétlépcsős hitelesítés¶