Autenticación¶

Registro de usuarios¶

La configuración por defecto de Weblate es utilizar python-social-auth, un formulario en el sitio web para gestionar el registro de nuevos usuarios. Después de confirmar su correo electrónico, un nuevo usuario puede contribuir o autenticarse utilizando uno de los servicios de terceros.

También puedes desactivar el registro de nuevos usuarios mediante REGISTRATION_OPEN.

Los intentos de autenticación están sujetos a Tipo limitante.

Dorsales de autenticación¶

Weblate se basa en Django para la autenticación. Esto incluye autenticación basada en contraseñas empotradas, autenticación social, y backend de autenticación de terceras partes para Django.

Utilizar autenticación embebida significa que puede importar la base de datos de otro proyecto basado en Django (consulte Migrar de Pootle).

Ver también

Configuración de autenticación describe cómo configurar la autenticación en la imagen oficial para Docker.

Autenticación por contraseña¶

Por defecto settings.py viene con un paquete razonable de AUTH_PASSWORD_VALIDATORS que asegura que las contraseñas débiles no son permitidas. Puede ajustar estos parámetros para coincidir su normativa de contraseña.

Adicionalmente, puedes además instalar django-zxcvbn-password-validator lo cual ofrece estimaciones bastante realistas de la dificultad de las contraseñas y permite rechazar las contraseñas por debajo de un cierto umbral.

Ver también

Autenticación por SAML¶

Added in version 4.1.1.

Distinto en la versión 5.12: Las dependencias para autenticación SAML no es incluida más larga en las extras predeterminada todo. Necesita incluir saml mientras instala el paquete Weblate utilizando pip (uv pip install Weblate[all,saml]).

Siga las instrucciones de Python Social Auth para la configuración. Diferencias notables:

Weblate soporta un único IDP que se debe llamar weblate en SOCIAL_AUTH_SAML_ENABLED_IDPS.
La URL de los metadatos XML de SAML es /accounts/metadata/saml/, la cual además es un ID de entidad.
EL URL de acceso es /accounts/complete/saml/ (además conocido como URL ACS).
Los siguientes ajustes se rellenan automáticamente: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Ejemplo de configuración:

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

Puedes generar una pareja de claves utilizando:

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

La configuración por defecto extrae los detalles del usuario de los atributos a continuación, configura tu IdP para proporcionarlos:

Atributo	Referencia de URI de SAML
Nombre completo	`urn:oid:2.5.4.3`
Nombre	`urn:oid:2.5.4.42`
Apellidos	`urn:oid:2.5.4.4`
Correo-e	`urn:oid:0.9.2342.19200300.100.1.3`
Apodo	`urn:oid:0.9.2342.19200300.100.1.1`

Cuando configura Weblate SP en su IdP, está recomendado elegir persistencia Nombre de formato ID.

Consejo

El ejemplo anterior y la imagen de Docker definen un IdP invocado weblate. Es posible que deba configurar esta cadena como Retransmisión en su IdP.

Nota

La autenticación de Weblate depende del parámetro RelayState que se pasa durante el proceso de autenticación. Esto necesita configurarse con algunos proveedores de identidad:

Como Enviar un RelayState Personal con Okta

Ver también

Autenticación LDAP¶

La autenticación LDAP puede lograrse mejor utilizando el paquete django-auth-ldap. Puedes instalarlo por los medios habituales:

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

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

Consejo

Este paquete está incluido en el contenedor Docker, véase Instalar con Docker.

Nota

Hay algunas incompatibilidades en el módulo LDAP 3.1.0 de Python, la cual podrían impedirte utilizar esa versión. Si se produce el error AttributeError: “module” object has no attribute “_trace_level”, podría ayudar la actualización de python-ldap a la versión 3.0.0.

Una vez que tengas el paquete instalado, lo puedes enlazar a la autenticación de 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

Nota

Deberías eliminar 'social_core.backends.email.EmailAuth' de la configuración AUTHENTICATION_BACKENDS, de lo contrario los usuarios podrán establecer tu contraseña en Weblate, y autenticarse usando eto. Mantener 'weblate.accounts.auth.WeblateUserBackend' todavía es necesario para hacer permisos y permitir a los usuarios anónimos. También te permitirá iniciar sesión usando una cuenta de administrador local, si la has creado (por ejemplo, usando createadmin).

Uso de la contraseña de enlace¶

Si no puedes usar el enlace directo para la autenticación, tendrás que utilizar la búsqueda y proporcionar un usuario para el enlace de la búsqueda. Por ejemplo:

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

Integración con 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

Ver también

Autenticación CAS¶

Se puede implantar una autenticación CAS al utilizar un paquete como Django CAS NG.

El primer paso consiste en revelar el campo Correo electrónico del usuario mediante CAS. Esto debe configurarse en el propio servidor CAS, y necesitará ejecutar al menos la versión 2 de CAS, ya que CAS v1 no admite atributos.

El segundo paso será actualizar Weblate para que utilice el servidor y los atributos de CAS.

Para instalar Django CAS NG:

uv pip install django-cas-ng

Una vez que haya instalado el paquete, puede conectarlo con el sistema de autenticación de Django; para ello, modifique el archivo 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")

Finalmente, se puede utilizar una señal para vincular el campo Correo electrónico y el objeto de usuario. Para que esto funcione, debe importar la señal del paquete django-cas-ng y conectar su código con esta señal. Realizar esto en el archivo de configuración puede causar problemas, por lo cual se recomienda ponerlo:

En el método django.apps.AppConfig.ready() de la configuración de su aplicación
En el archivo urls.py del proyecto (cuando no existan modelos)

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

Configurar la autenticación de Django de terceros¶

Generalmente cualquier programa adicional Django funciona con Weblate. Solo hay que seguir las instrucciones del programa adicional. Se recomienda tener el soporte de usuario Weblate instalado.

Ver también

Autenticación LDAP
Autenticación CAS

Normalmente la instalación consiste en agregar un soporte de autenticación en AUTHENTICATION_BACKENDS e instalar una aplicación de autenticación (si la hay) en INSTALLED_APPS:

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

INSTALLED_APPS += (
    # Install authentication app here
)

Autenticación en dos fases¶

Added in version 5.7.

Consejo

La autenticación en dos fases añade otra capa de seguridad a tu cuenta al requerir algo más que una contraseña para iniciar sesión.

Weblate admite los siguientes segundos factores:

Claves de seguridad (WebAuthn)

Se admiten tanto Passkeys como claves de seguridad.

Las Passkeys validan tu identidad mediante el tacto, el reconocimiento facial, una contraseña del dispositivo o un PIN, ya que incluyen la verificación del usuario.

Las claves de seguridad son credenciales WebAuthn que sólo pueden utilizarse como segundo factor de autenticación, y éstas solo validan la presencia del usuario.

Aplicaciones de autenticación (TOTP)

Las aplicaciones de autenticación y las extensiones de navegador como Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator, etc. generan contraseñas de un solo uso que se utilizan como segundo factor para verificar su identidad cuando se le solicita durante el inicio de sesión.

Códigos de recuperación

Los códigos de recuperación pueden utilizarse para acceder a tu cuenta si pierdes el acceso a tu dispositivo y no puedes recibir códigos de autenticación en dos fases.

Mantenga sus códigos de recuperación tan seguros como su contraseña. Te recomendamos guardarlos con un gestor de contraseñas como Bitwarden, 1Password, Authy o Keeper.

Cada usuario puede configurar esto en Cuenta y se requerirá un segundo factor para firmar además del método de autenticación existente.

Esto se puede aplicar a los usuarios a nivel de proyecto (consulte Autenticación en dos fases obligatoria) o de equipo. En implementaciones a nivel de sitio, también se puede usar para aplicar la autenticación de dos factores a todos los usuarios habilitándola en el equipo predeterminado Users, que se asigna automáticamente a los nuevos usuarios mediante automatic team assignment.

Los permisos de un equipo con autenticación de dos factores forzada no se aplicarán a los usuarios que no la tengan configurada.

Autenticación¶

Registro de usuarios¶

Dorsales de autenticación¶

Autenticación social¶

Autenticación por OpenID¶

Autenticación por GitHub¶

Autenticación de GitHub EE¶

Autenticación por Bitbucket¶

Google OAuth 2¶

OAuth 2 de Facebook¶

OAuth 2 de GitLab¶

Gitea OAuth 2¶

Microsoft Entra ID¶

Slack¶

Anulación de los nombres e iconos de los métodos de autenticación¶

Desactivar la autenticación por contraseña¶

Autenticación por contraseña¶

Autenticación por SAML¶

Autenticación LDAP¶

Uso de la contraseña de enlace¶

Integración con Active Directory¶

Autenticación CAS¶

Configurar la autenticación de Django de terceros¶

Autenticación en dos fases¶