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át szabályozás 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

PASSWORD_MINIMAL_STRENGTH, WEBLATE_MIN_PASSWORD_SCORE, Jelszóbiztonság

SAML-hitelesítés¶

Added in version 4.1.1.

A 5.12 verzióban változott: The dependencies for SAML authentication are no longer included in the default all extras. You need to include saml while installing the Weblate package using pip (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.
A SAML XML metaadat URL: /accounts/metadata/saml/.
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==",
        "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"
}

Az alapértelmezett konfiguráció a következő attribútumokból nyeri ki a felhasználói adatokat, az IDP-t úgy kell beállítani, hogy ezeket biztosítsa:

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`

Tipp

A fenti példa és a Docker-kép egy weblate nevű IDP (azonosításszolgáltató) definiálását mutatja be. Elképzelhető, hogy ezt az értéket az IDP-ben Relay (átjátszó) néven kell beállítani.

Lásd még

Configuring SAML in Docker, SAML

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

# 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

Django Authentication Using LDAP, Authentication

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.

Ezt projektszinten (lásd: Kétlépcsős azonosítás kényszerítése) vagy csapatszinten is kötelezővé lehet tenni.

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 Azure Active Directory¶

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¶