Kimlik doğrulama

Kullanıcı hesabı açma

Weblate varsayılan kurulumda, yeni açılan kullanıcıların hesaplarını işlemek için sitesindeki bir form olan python-social-auth kullanır. Yeni bir kullanıcı, e-posta adresini onayladıktan sonra, üçüncü taraf hizmetlerden birini kullanarak katkıda bulunabilir veya kimliğini doğrulayabilir.

Yeni kullanıcı hesaplarının açılmasını REGISTRATION_OPEN komutu ile de kapatabilirsiniz.

Kimlik doğrulama girişimleri Hızı sınırlaması değeriyle sınırlanır.

Kimlik doğrulama arka plan uygulamaları

Weblate kimlik doğrulaması için Django kullanır. Bunun içinde, yerleşik parola temelli kimlik doğrulama, sosyal ağ kimlik doğrulaması ve Django için üçüncü taraf kimlik doğrulama arka uçları bulunur.

Hazır Django çözümünü kullanmak, diğer Django temelli projelerin kullanıcı veri tabanını içe aktarabilmenizi sağlar (ayrıntılı bilgi almak için: Pootle üzerinden aktarmak).

Ayrıca bakınız

Kimlik doğrulama ayarları, belgesinde resmi Docker kalıbında kimlik doğrulamasının nasıl yapılandırılacağı anlatılmıştır.

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 Ortam değişkenlerinin yapılandırması to supply these Python settings; there are no dedicated environment variables for team mappings.

Ayrıca bakınız

External groups

Sosyal ağ kimlik doğrulaması

Weblate Welcome to Python Social Auth’s documentation! kullanarak, GitLab, Ubuntu, Fedora gibi birçok üçüncü taraf hizmeti ile kimlik doğrulamayı destekler.

Django Framework belgesinden genel yapılandırma yönergesine bakabilirsiniz.

Not

Weblate varsayılan olarak, doğrulanmış bir e-posta adresi sağlamak için üçüncü taraf kimlik doğrulama hizmetlerine güvenir. Kullanmak istediğiniz hizmetlerden bazıları bunu desteklemiyorsa, lütfen bunlar için FORCE_EMAIL_VALIDATION yapılandırması ile Weblate tarafında e-posta doğrulamasını zorunlu kılın. Örneğin:

SOCIAL_AUTH_OPENSUSE_FORCE_EMAIL_VALIDATION = True

Ayrıca bakınız

Pipeline

Provider names are normalized by Python Social Auth’s social_names pipeline step before Weblate initializes an empty full name. Existing full names are preserved. Weblate cleans and limits the resulting name and falls back to the username when the provider name is missing or invalid.

SOCIAL_AUTH_FIRSTLAST_FROM_FULL and SOCIAL_AUTH_FULL_FROM_FIRSTLAST control name conversion and both default to True. Backend-specific settings are supported, for example SOCIAL_AUTH_SAML_FULL_FROM_FIRSTLAST = False. See Name normalization for the conversion rules. Custom SOCIAL_AUTH_PIPELINE configurations should include social_core.pipeline.social_auth.social_names after social_details.

Tek tek arka uçları etkinleştirmek oldukça kolaydır. Bunun için yalnızca AUTHENTICATION_BACKENDS seçeneği ile bir kayıt ve olabilecek belirli bir kimlik doğrulama yöntemi için gerekli anahtarları eklemek gerekir. Bazı arka uçların varsayılan olarak kullanıcı e-posta adresi sağlamadığını, açıkça istemeniz gerektiğini, yoksa kullanıcılarının yaptığı katkıların hesabının Weblate tarafından doğru şekilde tutulamayacağını unutmayın.

İpucu

Kimlik doğrulama arka uçlarının çoğu için HTTPS gerekir. Site sunucunuzda HTTPS özelliğini kullanıma aldıktan sonra lütfen Weblate için ENABLE_HTTPS ya da Docker kapsayıcısı için WEBLATE_ENABLE_HTTPS seçeneklerini yapılandırarak doğru şekilde bildirilmesini sağlayın.

Ayrıca bakınız

Python Social Auth arka yüzü

Authentication storage cleanup

Weblate removes expired OpenID protocol associations and OpenID Connect login nonces in its hourly authentication cleanup task. OIDC login attempts have a 30-minute nonce lifetime by default; expiry is enforced during login even before the next cleanup runs. Linked accounts are preserved. Verification codes and partial pipelines retain their existing AUTH_TOKEN_VALID policy.

The social-auth database migration gives existing undated OIDC nonces a 30-minute grace period from upgrade. Follow the usual upgrade procedure with old login-serving processes stopped while applying migrations. For backend configuration, see OIDC (OpenID Connect).

OpenID kimlik doğrulaması

OpenID kullanan hizmetler için genellikle yalnızca onları kullanıma almak gerekir. Aşağıdaki bölüm OpenSUSE, Fedora ve Ubuntu için OpenID kimlik doğrulamasını kullanıma alır:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.email.EmailAuth",
    "social_core.backends.suse.OpenSUSEOpenId",
    "social_core.backends.ubuntu.UbuntuOpenId",
    "social_core.backends.fedora.FedoraOpenId",
    "weblate.accounts.auth.WeblateUserBackend",
)

Ayrıca bakınız

OpenID

GitHub kimlik doğrulaması

GitHub üzerinde bir OAuth uygulaması oluşturduktan sonra tüm erişim bilgilerini Weblate üzerine yazmanız gerekir:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.github.GithubOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_GITHUB_KEY = "GitHub Client ID"
SOCIAL_AUTH_GITHUB_SECRET = "GitHub Client Secret"
SOCIAL_AUTH_GITHUB_SCOPE = ["user:email"]

GitHub, geri çağırma adresi https://WEBLATE SUNUCUSU/accounts/complete/github/ olacak biçimde yapılandırılmalıdır.

Kuruluşlar için GitHub ve Takımlar için GitHub benzer kimlik doğrulama arka yüzleri vardır. Ayarları SOCIAL_AUTH_GITHUB_ORG_* ve SOCIAL_AUTH_GITHUB_TEAM_* olarak adlandırılmıştır ve SOCIAL_AUTH_GITHUB_ORG_NAME ya da SOCIAL_AUTH_GITHUB_TEAM_ID kapsamları için ek ayarlara gerek duyarlar. Geri çağırma adresleri https://WEBLATE SUNUCUSU/accounts/complete/github-org/ ve https://WEBLATE SUNUCUSU/accounts/complete/github-teams/ biçimindedir.

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

GitHub

GitHub EE kimlik doğrulaması

GitHub EE üzerinde bir OAuth uygulaması oluşturduktan sonra parolasını Weblate üzerine yazmanız gerekir:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.github_enterprise.GithubEnterpriseOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY = "GitHub OAuth App Client ID"
SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET = "GitHub OAuth App Client Secret"
SOCIAL_AUTH_GITHUB_ENTERPRISE_URL = "https://git.example.com/"
SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL = "https://git.example.com/api/v3/"
SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE = ["user:email"]

GitHub OAuth uygulaması geri çağırma adresi https://WEBLATE SUNUCUSU/accounts/complete/github-enterprise/ olarak yapılandırılmalıdır.

GitHub OAuth uygulaması yerine GitHub App da kullanılabilir. GitHub App ile depolar, kuruluş ve/veya kullanıcı düzeyinde izinler verilebilir. GitHub App kullanmaya karar verirseniz, Kullanıcılar - <E-posta adresleri> ve Kuruluş - <Üyeler> için Access: Read-only iznini vermeniz gerekir.

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

Backend classes

Bitbucket kimlik doğrulaması

Bitbucket üzerinde bir uygulama oluşturduktan sonra tüm parolalarını Weblate üzerine yazmanız gerekir:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.bitbucket.BitbucketOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY = "Bitbucket Client ID"
SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET = "Bitbucket Client Secret"
SOCIAL_AUTH_BITBUCKET_OAUTH2_VERIFIED_EMAILS_ONLY = True

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

Bitbucket

Google OAuth 2

Google OAuth 2 kullanmak için <https://console.developers.google.com/> adresinden bir uygulama kaydetmeniz gerekir.

Yönlendirme adresi: https://WEBLATE SERVER/accounts/complete/google-oauth2/.

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.google.GoogleOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_GOOGLE_OAUTH2_KEY = "Client ID"
SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET = "Client secret"

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

Google

Facebook OAuth 2

OAuth 2 hizmetlerinde her zamanki gibi, uygulamanızı Facebook üzerine kaydetmeniz gerekir. Bunu yaptıkran sonra, Weblate yapılandırmasını uygulamayı kullanacak biçimde ayarlayabilirsiniz:

Yönlendirme adresi: https://WEBLATE SERVER/accounts/complete/facebook/.

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.facebook.FacebookOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_FACEBOOK_KEY = "key"
SOCIAL_AUTH_FACEBOOK_SECRET = "secret"
SOCIAL_AUTH_FACEBOOK_SCOPE = ["email", "public_profile"]

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

Facebook

GitLab OAuth 2

GitLab OAuth 2 kullanmak için <https://gitlab.com/profile/applications> adresinden bir uygulama kaydetmeniz gerekir.

Yönlendirme adresi: https://WEBLATE SERVER/accounts/complete/gitlab/ and ensure you mark the read_user scope.

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.gitlab.GitLabOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_GITLAB_KEY = "Application ID"
SOCIAL_AUTH_GITLAB_SECRET = "Secret"
SOCIAL_AUTH_GITLAB_SCOPE = ["read_user"]

# If you are using your own GitLab
# SOCIAL_AUTH_GITLAB_API_URL = 'https://gitlab.example.com/'

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

GitLab

Gitea OAuth 2

Gitea OAuth 2 kullanmak için https://GITEA SERVER/user/settings/applications adresinden bir uygulama kaydetmeniz gerekir.

Yönlendirme adresi: https://WEBLATE SERVER/accounts/complete/gitea/.

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.gitea.GiteaOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_GITEA_KEY = ""
SOCIAL_AUTH_GITEA_SECRET = ""

# If you are using your own Gitea
SOCIAL_AUTH_GITEA_API_URL = "https://gitea.example.com/"

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Not

Yukarıdaki yapılandırma Forgejo ile de çalışır. Forgejo ile üretim dağıtımına bir örnek için Codeberg Translate bölümüne bakabilirsiniz.

Ayrıca bakınız

Gitea

Microsoft Entra ID

Azure Active Directory (Azure AD), Microsoft Entra ID olarak yeniden adlandırıldı. Weblate, altta yatan Python Social Auth arka uçları ve var olan dağıtımlarla uyumluluğu korumak için azuread-oauth2 ve azuread-tenant-oauth2 arka uç adlarını tutuyor.

Weblate, kimlik doğrulaması için genel ya da belirli kiracıları kullanacak şekilde yapılandırılabilir.

Yönlendirme adresi: Genel kiracılar için https://WEBLATE SERVER/accounts/complete/azuread-oauth2/ ve belirli kiracılar için https://WEBLATE SERVER/accounts/complete/azuread-tenant-oauth2/ biçimindedir.

Şunlara gerek duyacaksınız:

  • Uygulama (istemci) kimliği (Application (client) ID) Microsoft Entra yönetim merkezindeki uygulama kaydı özeti bölümünden alınabilir. Nesne kimliği (Object ID) Weblate üzerinde kullanılmaz.

  • Dizin (kiracı) kimliği (Directory (tenant) ID), genellikle istenen, kiracı kapsamlı kimlik doğrulaması için gereklidir.

  • Uygulama kaydı için bir istemci parolası oluşturduğunuzda Gizli değer (Secret value) yalnızca bir kez görüntülenir. Gizli kimlik (Secret ID) Weblate üzerinde kullanılmaz.

# Microsoft Entra ID common

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.azuread.AzureADOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# OAuth2 keys
SOCIAL_AUTH_AZUREAD_OAUTH2_KEY = ""
SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET = ""
# Microsoft Entra ID with Tenant

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.azuread_tenant.AzureADTenantOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Application (client) ID
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY = ""
# Secret value
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET = ""
# Directory (tenant) ID
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID = ""

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Slack

Slack OAuth 2 kullanmak için <https://api.slack.com/apps> adresinden bir uygulama kaydetmeniz gerekir.

Yönlendirme adresi: https://WEBLATE SERVER/accounts/complete/slack/.

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.slack.SlackOAuth2",
    "social_core.backends.email.EmailAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_SLACK_KEY = ""
SOCIAL_AUTH_SLACK_SECRET = ""

Not

Weblate, kimlik doğrulaması yapılırken belirtilen geri çağırma adresinde yapılandırılmış etki alanı bulunur. Adres uyuşmazlığıyla ilgili sorunlar görürseniz bu ayarı düzeltmek isteyebilirsiniz. Ayrıntılı bilgi almak için: Doğru site etki alanını ayarlayın.

Ayrıca bakınız

Slack

Kimlik doğrulama yöntemi adlarını ve simgelerini değiştirmek

Display names and bundled icons come from python-social-auth backend metadata. Weblate retains translated labels and local icons for its password and e-mail methods, and supplies its own fallback icon for providers without a logo. Add social_django.finders.SocialAuthIconFinder after the standard finders in STATICFILES_FINDERS to collect the provider icons from social-auth-core. The example and Docker settings include this finder. Run weblate collectstatic --noinput after upgrading.

You can override the authentication method display name and icon using settings as SOCIAL_AUTH_<NAME>_IMAGE and SOCIAL_AUTH_<NAME>_TITLE. For example overriding naming for Auth0 would look like:

SOCIAL_AUTH_AUTH0_IMAGE = "custom.svg"
SOCIAL_AUTH_AUTH0_TITLE = "Custom auth"

Relative image names retain the auth/ static directory convention. Existing bundled filenames, such as auth0.svg, also resolve to the shared social_auth/icons/ directory when no local override exists. Full HTTP URLs and data URLs continue to work.

Parola ile kimlik doğrulamayı kapatmak

E-posta ve parola kimlik doğrulaması AUTHENTICATION_BACKENDS bölümündeki social_core.backends.email.EmailAuth seçeneği kaldırılarak kapatılabilir. Temel Weblate işlevleri için gerekli olduğundan weblate.accounts.auth.WeblateUserBackend seçeneğini her zaman orada tutun.

E-posta kimlik doğrulamasını kullanımdan kaldırmak, e-posta ile ilgili tüm işlevleri (kullanıcı daveti ya da parola sıfırlama özelliği) kullanımdan kaldırır.

Tüyo

Yönetici arayüzü için, orada el ile oluşturduğunuz kullanıcılarda parola ile kimlik doğrulamasını kullanmayı sürdürebilirsiniz. /admin/login/ adresine gitmeniz yeterlidir.

Örneğin, yalnızca openSUSE Open ID hizmet sağlayıcısını kullanan kimlik doğrulaması şunu kullanarak yapılabilir:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.suse.OpenSUSEOpenId",
    "weblate.accounts.auth.WeblateUserBackend",
)

Parola ile kimlik doğrulama

Varsayılan settings.py dosyasında, zayıf parolalara izin vermeyen mantıklı bir AUTH_PASSWORD_VALIDATORS kümesi bulunur. Bu ayarı parola ilkenize uyacak şekilde özelleştirebilirsiniz.

Ek olarak, parola zorluğu ile ilgili oldukça gerçekçi öngörüler veren ve belirli bir eşiğin altında kalan parolaların reddedilmesini sağlayan django-zxcvbn-password-validator uygulamasını da kurabilirsiniz.

SAML kimlik doğrulaması

Added in version 4.1.1.

5.12 sürümünde değişti: SAML kimlik doğrulaması için bağımlılıklar artık varsayılan all eklerinde bulunmuyor. Weblate paketini pip kullanarak kurarken (uv pip install Weblate[all,saml]) saml paketini eklemeniz gerekir.

Lütfen yapılandırma için Python Social Auth yönergesini izleyin. Önemli farklar:

  • Weblate, SOCIAL_AUTH_SAML_ENABLED_IDPS içinde weblate olarak adlandırılması gereken tek kimlik hizmeti sağlayıcısını destekler.

  • SAML XML üst verileri adresi: /accounts/metadata/saml/, aynı zaman bir varlık kimliğidir.

  • Oturum açma adres: /accounts/complete/saml/ (ACS URL olarak da bilinir).

  • Şu seçenekler kendiliğinden doldurulur: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Örnek yapılandırma:

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

Şöyle yeni bir anahtar çifti oluşturabilirsiniz:

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

Varsayılan yapılandırma, şu özniteliklerden kullanıcı bilgilerini ayıklar. Kimlik hizmeti sağlayıcınızı bunları sağlayacak şekilde yapılandırın:

Öznitelik

SAML URI referansı

Ad soyad

urn:oid:2.5.4.3

Ad

urn:oid:2.5.4.42

Soyad

urn:oid:2.5.4.4

E-posta

urn:oid:0.9.2342.19200300.100.1.3

Kullanıcı adı

urn:oid:0.9.2342.19200300.100.1.1

Kimlik hizmeti sağlayıcınızda Weblate SP yapılandırırken, kalıcı Ad kimliği biçimini seçmeniz önerilir.

İpucu

Some identity providers (such as Microsoft Entra ID with multi-factor authentication) require disabling the default requestedAuthnContext in the SAML security configuration:

SOCIAL_AUTH_SAML_SECURITY_CONFIG = {"requestedAuthnContext": False}

In Docker, set WEBLATE_SAML_SECURITY_CONFIG instead.

İpucu

Yukarıdaki örnek ve Docker kalıbı weblate adlı bir kimlik hizmeti sağlayıcısı tanımlar. Bu dizgeyi kimlik hizmeti sağlayıcınızda Relay olarak yapılandırmanız gerekebilir.

Not

Weblate kimlik doğrulaması, kimlik doğrulama sürecinden geçirilecek RelayState parametresine dayanır. Bunun bazı kimlik sağlayıcılarda yapılandırılması gerekir:

LDAP kimlik doğrulaması

LDAP kimlik doğrulaması en iyi şekilde django-auth-ldap paketi kullanılarak sağlanabilir. Her zamanki gibi kurabilirsiniz:

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

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

İpucu

Bu paket Docker kapsayıcısı ile birlikte gelir. Ayrıntılı bilgi almak için: Docker ile kurmak.

Not

Python LDAP 3.1.0 modülünde, bu sürümü kullanmanızı engelleyebilecek bazı uyumsuzluklar vardır. AttributeError: ‘module’ nesnesinin ‘_trace_level’_ özniteliği yok hatasıyla karşılaşırsanız, python-ldap modülünü 3.0.0 sürümüne düşürmek yardımcı olabilir.

Paketi kurduktan sonra, Django kimlik doğrulaması ile bağlayabilirsiniz:

# 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

Not

AUTHENTICATION_BACKENDS ayarından ’social_core.backends.email.EmailAuth’ seçeneğini kaldırmalısınız. Yoksa kullanıcılar Weblate üzerinde kendi parolalarını ayarlayabilir ve bunu kullanarak kimlik doğrulaması yapabilir. İzinler almak ve anonim kullanıcılara kolaylık sağlamak için weblate.accounts.auth.WeblateUserBackend seçeneğinin tutulması hala gereklidir. Ayrıca, yerel bir yönetici hesabı oluşturduysanız (örneğin createadmin kullanarak) oturum açmanızı da sağlar.

BIND parolasını kullanarak

Kimlik doğrulaması için doğrudan BIND kullanamıyorsanız, aramayı kullanmanız ve arama için bağlanacak bir kullanıcı belirtmeniz gerekir. Örneğin:

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 bütünleştirmesi

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

CAS kimlik doğrulaması

CAS kimlik doğrulaması, Django CAS NG gibi bir paket kullanılarak yapılabilir.

Birinci adım, kullanıcının e-posta alanını CAS aracılığıyla açıklamaktır. Bunun CAS sunucusunun kendisinde yapılandırılması gerekir ve CAS v1 öznitelikleri tarafından desteklenmediğinden en az CAS v2 çalıştırmanız gerekir.

İkinci adım, Weblate yapılandırmasını CAS sunucunuzu ve özniteliklerinizi kullanacak şekilde güncellemektir.

Django CAS NG kurmak için:

uv pip install django-cas-ng

Paketi kurduktan sonra, settings.py dosyasını değiştirerek Django kimlik doğrulama sistemiyle bağlantı kurabilirsiniz:

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

Son olarak, e-posta alanını kullanıcı nesnesiyle eşlemek için bir sinyal kullanabilirsiniz. Bunun çalışması için sinyali django-cas-ng paketinden içe aktarmanız ve kodunuzu bu sinyale bağlamanız gerekir. Bunu ayarlar dosyasında yapmak sorunlara neden olabilir. Bu nedenle şunları koymanız önerilir:

  • Uygulamanızın yapılandırmasında django.apps.AppConfig.ready() yöntemi

  • Projenin urls.py dosyasında (herhangi bir model var olmadığında)

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

Üçüncü taraf Django kimlik doğrulamasını yapılandırmak

Genellikle herhangi bir Django kimlik doğrulama uygulama eki Weblate ile çalışmalıdır. Yalnızca eklentinin yönergesini izleyin. Weblate kullanıcı arka ucunu kurulmuş olarak tutmayı unutmayın.

Genellikle kurulum, AUTHENTICATION_BACKENDS seçeneğine bir kimlik doğrulama arka ucu eklemekten ve INSTALLED_APPS içine bir kimlik doğrulama uygulaması (varsa) kurmaktan oluşur:

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

INSTALLED_APPS += (
    # Install authentication app here
)

İki adımlı doğrulama

Added in version 5.7.

İpucu

İki adımlı doğrulama, oturum açmak için parola dışında bir bilgi daha isteyerek hesabınıza ek bir güvenlik katmanı ekler.

Weblate, şu ikinci adımları destekler:

Güvenlik anahtarları (WebAuthn)

Geçiş anahtarları ve güvenlik anahtarlarının ikisi de desteklenir.

Geçiş anahtarları kullanıcı doğrulamasını da içerdiğinden, kimliğinizi dokunma, yüz tanıma, aygıt parolası veya PIN kodu ile doğrular.

Güvenlik anahtarları, yalnızca ikinci bir doğrulama adımı olarak kullanılabilen WebAuthn kimlik bilgileridir ve bunlar yalnızca kullanıcının varlığını doğrular.

When signing in on a new computer or in a different browser, your passkey might not be available. Use a device where the passkey is available, or connect your registered security key. A verification error can mean that the request timed out, was canceled, or that the credential is unavailable; it does not identify the exact cause.

You can also select another configured verification method on the sign-in page, such as Use recovery codes. If you cannot use any configured method, contact the site administrator for help.

Kimlik doğrulama uygulamaları (tek kullanımlık parola)

Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator gibi kimlik doğrulama uygulamaları ve tarayıcı eklentileri, oturum açma sırasında istendiğinde kimliğinizi doğrulamak için ikinci adım olarak kullanılan zamana bağlı tek kullanımlık parolalar üretir.

Registration becomes active only after you verify a code from the app. Complete registration within 24 hours; otherwise start again with a 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. Opening registration in another browser session shows the same QR code until registration is completed or expires.

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

Kurtarma kodları

Aygıtınıza erişiminizi kaybetmeniz ve iki adımlı doğrulama kodlarını alamamanız durumunda hesabınıza erişmek için kurtarma kodlarını kullanabilirsiniz.

Kurtarma kodlarınızı parolanız gibi güvende tutun. Bunları Bitwarden, 1Password, Authy veya Keeper gibi bir parola yöneticisine kaydetmenizi öneririz.

../_images/authentication.webp

Her kullanıcı bunu Hesap bölümünden yapılandırabilir. Ardından oturum açmak için var olan kimlik doğrulama yöntemine ek olarak ikinci adımın kullanılması gerekecektir.

Bu, projede kullanıcı veya takım düzeyinde uygulanabilir (ayrıntılı bilgi almak için Dayatılan iki adımlı doğrulama). Site genelindeki dağıtımlarda, bu, kendiliğinden takım ataması tarafından yeni kullanıcılara kendiliğinden atanan varsayılan Kullanıcılar takımında etkinleştirerek tüm kullanıcılara iki adımlı doğrulamayı uygulamak için de kullanılabilir.

İki adımlı kimlik doğrulaması uygulanan bir takımın izinleri, bu özelliği yapılandırmamış kullanıcılara uygulanmaz.