인증¶

사용자 등록¶

Weblate의 기본 설정은 python-social-auth를 사용하여 새 사용자 등록을 처리합니다. 이메일을 확인한 후 새 사용자는 서드파티 서비스를 사용하여 기여하거나 인증할 수 있습니다.

REGISTRATION_OPEN 을 사용하여 새 사용자 등록을 비활성화할 수도 있습니다.

인증 시도는 속도 제한 의 적용을 받습니다.

인증 백엔드¶

Weblate는 인증을 위해 Django에 의존합니다. 여기에는 내장 비밀번호 기반 인증, 소셜 인증, Django용 서드파티 인증 백엔드가 포함됩니다.

Django의 내장 인증을 사용하면 다른 Django 기반 프로젝트의 사용자 데이터베이스를 가져올 수 있습니다 ( Pootle에서 마이그레이션 참조).

인증 설정 는 공식 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 환경 변수를 넘어서는 설정 to supply these Python settings; there are no dedicated environment variables for team mappings.

External groups

비밀번호 인증¶

기본 settings.py 에는 약한 비밀번호가 허용되지 않도록 하는 합리적인 AUTH_PASSWORD_VALIDATORS 설정이 포함되어 있습니다. 비밀번호 정책에 맞게 이 설정을 사용자 지정할 수 있습니다.

또한 비밀번호 난이도를 상당히 현실적으로 추정하고 특정 임계값 미만의 비밀번호를 거부할 수 있는 django-zxcvbn-password-validator 를 설치할 수도 있습니다.

OpenID Connect identity provider¶

Added in version 2026.11.

Weblate can act as an optional OpenID Connect (OIDC) identity provider for other applications. This is separate from signing in to Weblate using an external OIDC provider.

Install the oidc extra (uv pip install Weblate[oidc]). Generate a signing key and keep it outside version control:

openssl genrsa -out /path/to/oidc.key 4096

Enable OIDC_PROVIDER_ENABLED, add the optional applications, and configure OAUTH2_PROVIDER in your settings:

from pathlib import Path

OIDC_PROVIDER_ENABLED = True
INSTALLED_APPS += ["weblate.oidc", "oauth2_provider"]
OAUTH2_PROVIDER = {
    "OIDC_RSA_PRIVATE_KEY": Path("/path/to/oidc.key").read_text(encoding="utf-8"),
}

Run migrate before starting Weblate and its workers. Disabled installations do not need these applications, dependencies, or database tables. For Docker, see WEBLATE_OIDC_PROVIDER_ENABLED.

Register each client in Django administration under Applications. Select Authorization code and RSA with SHA-256. For clients supporting a secret, select Confidential and securely copy the generated client ID and secret. Secrets are hashed when saved. For clients without a secret, select Public; S256 PKCE is required for both client types. Register the client’s exact HTTPS callback URL. Only select Skip authorization for trusted clients; other clients require user consent before accessing identity information.

The issuer is the canonical Weblate site URL followed by /oidc, including any URL_PREFIX. The discovery URL is the issuer followed by /.well-known/openid-configuration. Configure clients to use this discovery URL, authorization code flow, S256 PKCE, and scopes openid profile email. Confidential-client authentication supports HTTP Basic or a form-encoded client secret. For Zammad, register a public client, set its issuer to the Weblate issuer URL, select sub as the UID field, request openid profile email, and enable PKCE. Its callback is https://zammad.example.com/auth/openid_connect/callback. Nextcloud’s user_oidc app can use a confidential client with the discovery URL. Shared logout and automatic client registration are not provided.

Authorization requests can use GET or form-encoded POST. Clients exchange tokens and fetch UserInfo through their servers.

Clients can request fresh authentication using prompt=login or limit the age of the existing authentication using max_age in seconds. The limit also applies when submitting consent. max_age=0 always requires a new login. With prompt=none, Weblate returns login_required or consent_required when authentication or consent needs user interaction.

Federated sign-in can reuse an upstream session without revealing its authentication time. These sign-ins omit auth_time from ID tokens and cannot satisfy prompt=login or max_age requests; Weblate returns login_required instead. Use a password-based sign-in or e-mail verification when fresh authentication is required. A failed freshness request does not prevent later ordinary federated sign-ins.

The sub claim is the Weblate user ID as a string, stable across username and e-mail changes. The profile scope adds preferred_username, name, and family_name; both name claims contain Weblate’s full name. The email scope adds email and email_verified. Verification is reported only when the current address has a recorded verification. Claims are available in ID tokens and from /oidc/userinfo/ using an access token.

When 법적 모듈 is installed, clients can additionally request the optional weblate:legal scope. It adds weblate_tos_version to ID tokens and UserInfo, containing the version the user actually accepted as an ISO date, for example "2026-09-01". Older accepted versions are returned unchanged; the claim is omitted when no acceptance is recorded. Reading it does not record consent or expose the acceptance timestamp, IP address, or user agent. Without the legal module, this scope is unavailable.

Receiving servers using the same legal package, such as wllegal, can use this date to match their legal version. They must explicitly trust the issuer and match the accepted version to their own documents before suppressing local confirmation. This provider only exposes the information; accepting shared consent on receiving Weblate servers requires separate integration.

New browser sessions created for OIDC sign-in expire after 60 seconds, including when sign-in requires 2단계 인증. Existing browser sessions keep their expiry policy. Sessions created before the provider recorded an authentication time require a fresh sign-in before authorizing a client. If the browser session expires while the consent page is open, submitting the form restarts sign-in and displays a new consent page. The earlier approval or denial is discarded; the user must submit the new form. Concurrent authorization attempts are tracked separately. Pending attempts expire after 15 minutes; starting more than 16 discards the oldest attempt.

Access and ID tokens last one hour. Refresh tokens rotate on use and expire after 30 days of inactivity beyond their associated access token’s expiry. ID tokens retain the original authentication time across refreshes, including its absence for federated sign-ins, even when the user signs in again elsewhere. Reusing an already rotated refresh token revokes its token family. Tokens work independently of the browser session and do not authorize Weblate REST API access. Account removal deletes provider credentials, and inactive accounts cannot authorize or use provider tokens. Celery periodically cleans expired credentials.

To rotate signing keys, replace OIDC_RSA_PRIVATE_KEY and retain old private keys in OIDC_RSA_PRIVATE_KEYS_INACTIVE until outstanding ID tokens and cached key sets have expired. Only public key material is published by JWKS.

When migrating a client from SAML, explicitly map its existing identities to the OIDC issuer and subject. Do not assume SAML NameIDs equal OIDC subjects, or link accounts solely by matching e-mail addresses. For weblate.org, existing accounts are linked by persistent SAML provider/identity pairs; its client integration and identity mapping require a separate migration.

SAML 인증¶

Added in version 4.1.1.

버전 5.12에서 변경: SAML 인증의 종속 성분은 더 이상 기본 all 추가 항목에 포함되지 않습니다. pip을 사용하여 Weblate 패키지를 설치할 때 saml 을 포함해야 합니다 (uv pip install Weblate[all,saml]).

구성에 대해서는 Python Social Auth 지침을 따르세요. 주요 차이점:

Weblate는 SOCIAL_AUTH_SAML_ENABLED_IDPS 에서 weblate 로 지정해야 하는 단일 IDP를 지원합니다.
SAML XML 메타데이터 URL은 /accounts/metadata/saml/ 이며, 엔티티 ID이기도 합니다.
로그인 URL은 /accounts/complete/saml/ 입니다 (ACS URL이라고도 함).
다음 설정은 자동으로 채워짐: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

예시 설정:

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

다음을 사용하여 새 키 쌍을 생성할 수 있음:

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

기본 설정은 다음 속성에서 사용자 정보를 추출합니다. IdP에서 이를 제공하도록 설정하세요:

속성	SAML URI 참조
성명	`urn:oid:2.5.4.3`
이름	`urn:oid:2.5.4.42`
성	`urn:oid:2.5.4.4`
이메일	`urn:oid:0.9.2342.19200300.100.1.3`
사용자 이름	`urn:oid:0.9.2342.19200300.100.1.1`

IdP에서 Weblate SP를 구성할 때, 영구 Name ID 형식 을 선택하는 것이 권장됩니다.

힌트

일부 ID 공급자(예: multi-factor authentication을 지원하는 Microsoft Entra ID)는 SAML 보안 구성에서 기본값인 requestedAuthnContext 를 비활성화해야 합니다.

SOCIAL_AUTH_SAML_SECURITY_CONFIG = {"requestedAuthnContext": False}

Docker 환경에서는 대신 WEBLATE_SAML_SECURITY_CONFIG 를 지정하세요.

힌트

위의 예시와 Docker 이미지는 weblate 라는 IdP를 정의합니다. IdP에서 이 문자열을 Relay 로 설정해야 할 수 있습니다.

참고

Weblate 인증은 인증 프로세스를 통해 RelayState 매개변수가 전달되는 것에 의존합니다. 일부 ID 제공자에서는 이를 설정해야 함:

Okta에서 사용자 정의 RelayState 보내기

LDAP 인증¶

LDAP 인증은 django-auth-ldap 패키지를 사용하여 가장 잘 구현할 수 있습니다. 일반적인 방법으로 설치할 수 있음:

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

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

힌트

이 패키지는 Docker 컨테이너에 포함되어 있습니다 ( Docker를 사용한 설치 참조).

참고

Python LDAP 3.1.0 모듈에는 일부 비호환성이 있어 해당 버전을 사용하지 못할 수 있습니다. AttributeError: ‘module’ object has no attribute ‘_trace_level’ 오류가 발생하면 python-ldap를 3.0.0으로 다운그레이드하면 해결될 수 있습니다.

패키지를 설치한 후 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

참고

AUTHENTICATION_BACKENDS 설정에서 'social_core.backends.email.EmailAuth' 를 제거해야 합니다. 그렇지 않으면 사용자가 Weblate에서 비밀번호를 설정하고 이를 사용하여 인증할 수 있습니다. 권한 설정 및 익명 사용자 지원을 위해 'weblate.accounts.auth.WeblateUserBackend' 는 유지해야 합니다. 이를 통해 로컬 관리 계정 (예: createadmin 으로 생성)으로 로그인할 수도 있습니다.

바인드 비밀번호 사용¶

직접 바인드를 인증에 사용할 수 없는 경우, 검색을 사용하고 검색을 위한 바인드 사용자를 제공해야 합니다. 예:

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 통합¶

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 인증¶

CAS 인증은 Django CAS NG 와 같은 패키지를 사용하여 구현할 수 있습니다.

1단계는 CAS를 통해 사용자의 이메일 필드를 공개하는 것입니다. 이는 CAS 서버에서 직접 구성해야 하며, CAS v1은 속성을 전혀 지원하지 않으므로 최소 CAS v2를 실행해야 합니다.

2단계는 Weblate를 업데이트하여 CAS 서버와 속성을 사용하도록 하는 것입니다.

Django CAS NG 설치:

uv pip install django-cas-ng

패키지를 설치한 후 settings.py 파일을 수정하여 Django 인증 시스템에 연결할 수 있음:

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

마지막으로 시그널을 사용하여 이메일 필드를 사용자 객체에 매핑할 수 있습니다. 이를 위해 django-cas-ng 패키지에서 시그널을 가져와 코드를 이 시그널에 연결해야 합니다. 설정 파일에서 이 작업을 하면 문제가 발생할 수 있으므로 다음 위치에 배치하는 것이 좋음:

앱 설정의 django.apps.AppConfig.ready() 메서드 내
프로젝트의 urls.py 파일 내 (모델이 없는 경우)

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

서드파티 Django 인증 설정¶

일반적으로 모든 Django 인증 플러그인이 Weblate에서 작동합니다. 플러그인 지침을 따르되, Weblate 사용자 백엔드를 유지하는 것을 잊지 마세요.

LDAP 인증
CAS 인증

일반적으로 설치에는 AUTHENTICATION_BACKENDS 에 인증 백엔드를 추가하고 (존재하는 경우) 인증 앱을 INSTALLED_APPS 에 설치하는 것이 포함됨:

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

INSTALLED_APPS += (
    # Install authentication app here
)

2단계 인증¶

Added in version 5.7.

힌트

2단계 인증은 비밀번호 이외에 다른 정보도 요구하여 계정의 보안을 한 단계 더 강화합니다.

Weblate는 다음과 같은 2차 인증 요소를 지원함:

보안 키 (WebAuthn)

패스키와 보안 키 모두 지원됩니다.

패스키는 사용자 확인을 포함하므로 터치, 얼굴 인식, 기기 비밀번호 또는 PIN을 사용하여 신원을 확인합니다.

보안 키는 2차 인증 요소로만 사용할 수 있는 WebAuthn 자격 증명이며, 사용자의 존재 여부만 확인합니다.

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.

인증 앱 (TOTP)

Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator 등의 인증 앱 및 브라우저 확장 프로그램은 로그인 시 본인 확인을 위한 2차 인증 요소로 사용되는 시간 기반 일회용 비밀번호를 생성합니다.

Registration becomes active only after you verify a code from the app. Complete registration within 10 minutes of confirming your sign-in method; otherwise confirm it again and use the 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. Confirming your sign-in method in another browser session invalidates the pending QR code and starts a new registration.

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

복구 코드

복구 코드는 기기에 대한 접근 권한을 잃고 2단계 인증 코드를 받을 수 없는 경우 계정에 접근하는 데 사용할 수 있습니다.

복구 코드를 비밀번호만큼 안전하게 보관하세요. Bitwarden, 1Password, Authy 또는 Keeper와 같은 비밀번호 관리자에 저장하는 것을 권장합니다.

Each user can configure this in 보안 and second factor will be required to sign in addition to the existing authentication method.

Before registering the first authenticator app or security key, confirm your existing sign-in method. Enter your current password, including one verified by a configured Django authentication backend such as LDAP, or sign in again through an already connected provider. If neither method is available, contact an administrator to recover access. Registering a new factor does not count as a recent second-factor verification for other sensitive actions, such as creating a project token; complete a separate second-factor challenge for those actions.

Viewing the personal API key and changing credentials, access permissions, or account status requires credential verification from the last 10 minutes in a browser session. This includes managing project members and tokens, teams, roles, user accounts, and project visibility. Weblate prompts for a second factor when one is configured. Otherwise, enter your current password, verify through a configured Django authentication backend, or sign in again through an already connected provider. Account deletion still requires confirmation through a link sent to your e-mail address. API token requests continue to use token authentication.

이는 프로젝트 ( 강제 2단계 인증 참조) 또는 팀 수준에서 사용자에 대해 강제할 수 있습니다. 사이트 전체 배포에서는 기본 사용자 팀에서 활성화하여 모든 사용자에 대해 2단계 인증을 강제할 수도 있습니다. 이 팀은 자동 팀 할당 에 의해 새 사용자에게 자동으로 배정됩니다.

2단계 인증이 강제된 팀의 권한은 이를 설정하지 않은 사용자에게 적용되지 않습니다.

인증¶

사용자 등록¶

인증 백엔드¶

Teams from identity providers¶

소셜 인증¶

Authentication storage cleanup¶

OpenID 인증¶

GitHub 인증¶

GitHub EE 인증¶

Bitbucket 인증¶

Google OAuth 2¶

Facebook OAuth 2¶

GitLab OAuth 2¶

Gitea OAuth 2¶

Microsoft Entra ID¶

Slack¶

Weblate OpenID Connect¶

인증 방법 이름 및 아이콘 재정의¶

비밀번호 인증 비활성화¶

비밀번호 인증¶

OpenID Connect identity provider¶

SAML 인증¶

LDAP 인증¶

바인드 비밀번호 사용¶

Active Directory 통합¶

CAS 인증¶

서드파티 Django 인증 설정¶

2단계 인증¶