Authentification

Enregistrement utilisateur

La configuration par défaut est d’utiliser python-social-auth, un formulaire web pour gérer les inscriptions de nouveaux utilisateurs. Après confirmation de son e-mail, on peut contribuer et s’authentifier en utilisant des services tiers.

Vous pouvez aussi désactiver les inscriptions de nouveaux utilisateurs en utilisant REGISTRATION_OPEN.

Le nombre de tentatives d’authentification est sujet à Limite de requêtes.

Backends d’authentification

La solution intégrée de Django est utilisée pour l’authentification, et inclue différents services sociaux pour le faire. Son utilisation signifie que vous pouvez importer la base de donnés d’utilisateurs d’autres projets basés sur Django (voir Migrating from Pootle).

De plus Django peut aussi être configuré pour utiliser d’autre méthodes d’authentification.

Voir aussi

Paramètres d’authentification décrit comment configurer l’authentification sur l’image Docker officielle.

Authentification sociale

Grâce à Welcome to Python Social Auth’s documentation!, Weblate supporte l’authentification par différents services tiers comme GitLab, Ubuntu, Fedora, etc.

Merci de consulter leur documentation pour des instructions de configuration générique dans Django Framework.

Note

Par défaut, Weblate sur des services tiers d’authentification pour confirmer les adresses e-mail. Si certains services de votre choix ne le supportent pas, merci d’imposer la confirmation de l’email en configurant FORCE_EMAIL_VALIDATION. Par exemple :

SOCIAL_AUTH_OPENSUSE_FORCE_EMAIL_VALIDATION = True

Voir aussi

Pipeline

Activer d’autres backends est plutôt simple, il suffit d’ajouter une ligne à AUTHENTICATION_BACKENDS et les clefs nécessaires à une méthode d’authentification donnée. Notez que certains backends ne fournissent pas d’adresse e-mail utilisateur par défaut, vous devez la demander explicitement, sinon Weblate ne sera pas en mesure de créditer les contributions des utilisateurs comme il se doit.

Indication

La plupart des « backends » d’authentification nécessitent HTTPS. Une fois que HTTPS est activé sur votre serveur web, veuillez configurer Weblate pour qu’il l’annonce correctement en utilisant ENABLE_HTTPS, ou WEBLATE_ENABLE_HTTPS dans un conteneur Docker.

Authentification OpenID

Pour les services reposant sur OpenID il n’y a généralement qu’à les activer. La section suivante activer l’authentification avec OpenID pour OpenSUSE, Fedora et Ubuntu :

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

Voir aussi

OpenID

S’authentifier avec GitHub

Vous devez créer une application OAuth sur Github et confier à Weblate tous ses petits secrets :

# 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 doit être configuré pour avoir une URL de rappel telle que https://WEBLATE SERVER/accounts/complete/github/.

Il existe des serveurs d’authentification similaires pour « Github for Organizations » et « Github for Teams ». Leurs paramètres sont appelés SOCIAL_AUTH_GITHUB_ORG_*, SOCIAL_AUTH_GITHUB_TEAM_*, et ils nécessitent un paramétrage supplémentaire de SOCIAL_AUTH_GITHUB_ORG_NAME ou SOCIAL_AUTH_GITHUB_TEAM_ID. Leurs URLs de rappel sont https://WEBLATE SERVER/accounts/complete/github-org/``et ``https://WEBLATE SERVER/accounts/complete/github-teams/.

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

GitHub

Authentification GitHub EE

Vous devez créer une application OAuth sur Github EE et confier ensuite à Weblate tous ses petits secrets :

# 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 doit être configuré pour avoir une URL de rappel telle que https://WEBLATE SERVER/accounts/complete/github-enterprise/.

Au lieu de GitHub OAuth App, vous pouvez aussi utiliser GitHub App. Avec GitHub App il est possible d’attributer des droits sur les répertoires, l’organisation et/ou le niveau utilisateur. Si vous choisissez d’utiliser GitHub App, vous devez activer les droits Accès : Read-only pour les Utilisateurs - <Adresses courriel> et les Organisations - <Membres>.

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

GitHub Enterprise

S’authentifier avec Bitbucket

Vous devez créer une application sur Bitbucket et confier à Weblate tous ses petits secrets :

# 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

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

Bitbucket

Google OAuth 2

Pour utiliser Google OAuth 2, vous devez enregistrer une application sur <https://console.developers.google.com/> et activer l’API Google+.

The redirect URL is 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"

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

Google

Facebook OAuth 2

Comme d’habitude avec les services OAuth 2, vous devez enregistrer une application chez Facebook. Une fois que c’est fait, vous pouvez configurer Weblate pour l’utiliser :

The redirect URL is 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"]

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

Facebook

GitLab OAuth 2

Pour utiliser GitLab OAuth 2, vous devez enregistrer une application sur <https://gitlab.com/profile/applications>.

L’URL de redirection est 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/'

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

GitLab

Gitea OAuth 2

Pour utiliser Gitea OAuth 2, vous devez enregistrer une application sur https://GITEA SERVER/user/settings/applications.

L’URL de redirection est 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/"

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Note

La configuration ci-dessus fonctionne également avec Forgejo ; pour un exemple de déploiement en production avec Forgejo, voir Codeberg Translate

Voir aussi

Gitea

Active Directory Microsoft Azure

Weblate peut être configuré pour utiliser des tenants communs ou spécifiques à l’authentification.

L’URL de redirection est https://WEBLATE SERVER/accounts/complete/azuread-oauth2/ pour les communs et https://WEBLATE SERVER/accounts/complete/azuread-tenant-oauth2/ pour les tenants spécifiques à l’authentification.

Vous aurez besoin des éléments suivants :

  • L”identifiant de l’application du client peut être obtenu à partir de la page de l’application. *Object ID*n’est pas utilisé dans Weblate.

  • Directory (tenant) ID is needed for tenant scoped authentication, what is usually desired.

  • Secret value is displayed once you generate a secret for an application. Secret ID is not used in Weblate.

# Azure AD 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 = ""
# Azure AD 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 = ""

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Slack

For using Slack OAuth 2, you need to register an application at <https://api.slack.com/apps>.

L’URL de redirection est 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 = ""

Note

La callback URL fournie par Weblate pendant l’authentification inclue le domaine configuré. En cas d’erreurs sur l’URL, vous devriez pouvoir arranger cela. Voir Set correct site domain.

Voir aussi

Slack

Ignorer les noms et les icônes des méthodes d’authentification

Vous pouvez remplacer le nom affiché et l’icône de la méthode d’authentification en utilisant des paramètres comme SOCIAL_AUTH_<NAME>_IMAGE et SOCIAL_AUTH_<NAME>_TITLE. Par exemple le remplacement du nom pour la méthode d’authentification utilisant Auth0 ressemblerait à ceci :

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

Désactiver l’authentification par mot de passe

L’authentification par e-mail et mot de passe peut être désactivée en supprimant social_core.backends.email.EmailAuth de AUTHENTICATION_BACKENDS. Conservez toujours weblate.accounts.auth.WeblateUserBackend là, c’est nécessaire pour les fonctionnalités essentielles de Weblate.

Désactiver l’authentification par adresse e-mail désactivera toutes les fonctionnalités liées aux e-mails – l’invitation d’utilisateur ou la fonctionnalité de réinitialisation de mot de passe.

Astuce

Vous pouvez toujours utiliser l’authentification par e-mail et mot de passe sur l’interface d’admin pour les utilisateurs créés manuellement. Allez simplement sur /admin/login/.

Par example, l’authentification utilisant seulement openSUSE OpenID peut être réalisée comme suit :

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

S’authentifier par mot de passe

Le fichier par défaut settings.py vient avec un ensemble raisonnable de AUTH_PASSWORD_VALIDATORS :

  • Les mots de passent ne peuvent être similaires aux autres informations personnelles.

  • Les mots de passe doivent contenir au moins 10 caractères.

  • Les mots de passe ne peuvent être communément employés.

  • Les mots de passe ne peuvent être entièrement numériques.

  • Les mots de passe ne peuvent consister en un seul caractère ou que des espaces.

  • Les mots de passe ne peuvent contenir un mot de passe utilisé dans le passé.

Vous pouvez personnaliser ces paramètres pour les faire correspondre à votre politique de mots de passe.

De plus vous pouvez aussi installer django-zxcvbn-password qui donne une estimation plutôt réaliste de la complexité d’un mot de passe et permet de les rejeter en dessous d’un certain seuil.

S’authentifier avec SAML

Ajouté dans la version 4.1.1.

Merci de suivre les instructions d’authentification sociale spécifiques à python pour la configuration. Differences notable :

  • Weblate supporte single IDP qui doit être appelé weblate dans SOCIAL_AUTH_SAML_ENABLED_IDPS.

  • L’URL SAML de metadonnées XML est /accounts/metadata/saml/.

  • Les paramètres suivants sont automatiquement remplis dans : SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Exemple de configuration :

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

La configuration par défaut extrait les détails de l’utilisateur depuis les attributs suivants, configurer votre IDP pour les remettre :

Attribut

Reference de l’URI SAML

Nom complet

urn:oid:2.5.4.3

Prénom

urn:oid:2.5.4.42

Nom de famille

urn:oid:2.5.4.4

Adresse courriel

urn:oid:0.9.2342.19200300.100.1.3

Nom d’utilisateur

urn:oid:0.9.2342.19200300.100.1.1

Indication

L’exemple ci-dessus et l’image Docker définissent un IDP appelé weblate. Vous devrez peut-être configurer cette chaîne en tant que Relay dans votre IDP (fournisseur d’identité).

S’authentifier avec LDAP

C’est mieux de s’authentifier avec LDAP en utilisant le paquet django-auth-ldap. Vous pouvez l’installer comme d’habitude :

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

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

Indication

Ce package est inclus dans le conteneur Docker, voir Installing using Docker.

Note

Des incompatibilités dans le module Python LDAP 3.1.0 peuvent vous empêcher d’utiliser cette version. Si vous obtenez l’erreur AttributeError : “module” object has no attribute “_trace_level”, le retour à la version 3.0.0 de python-ldap pourrait résoudre le problème.

Une fois que le paquet est installé, vous pouvez le relier à l’authentification 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",
}

# Hide the registration form
REGISTRATION_OPEN = False

Note

Vous devez supprimer 'social_core.backends.email.EmailAuth' du paramètre AUTHENTICATION_BACKENDS, sinon les utilisateurs seront en mesure de définir leur mot de passe sur Weblate et de s’authentifier avec. Garder 'weblate.accounts.auth.WeblateUserBackend' est encore nécessaire pour gérer les permissions et autoriser l’utilisation anonyme. Cela permet aussi de s’identifier avec un compte administrateur local, si vous en avez créé un (p. ex. en utilisant createadmin).

En utilisant le mot de passe bind

Si vous ne pouvez pas utiliser la liaison directe pour l’authentification, vous devrez utiliser la recherche, et fournir un utilisateur à lier pour la recherche. Par exemple :

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

Intégration avec 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

S’authentifier avec CAS

On peut s’authentifier avec CAS en utilisant un paquet comme django-cas-ng.

La première étape est de révéler le champ e-mail de l’utilisateur via CAS. Cela doit être configuré sur le serveur de CAS, et demande d’utiliser au moins CAS v2 vu que CAS v1 ne supporte pas du tout les attributs.

L’étape suivante est de mettre à jour Weblate pour utiliser votre server CAS et les attributs.

Pour installer django-cas-ng :

uv pip install django-cas-ng

Une fois que le paquet est installé vous pouvez relier au système d’authentification Django en modifiant le fichier 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")

Au final, un signal peut être utiliser pour assigner le champ e-mail à l’objet utilisateur. Pour que cela fonctionne, vous devez importer le signal depuis le paquet django-cas-ng et connecter votre code à ce signal. Faire cette manipulation depuis les fichiers de configuration peut être problématique, alors on conseille de faire différemment :

  • Dans la méthode django.apps.AppConfig.ready() de la configuration de l’application

  • Dans le fichier urls.py du projet (quand il n’existe pas de modèle)

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

Voir aussi

Django CAS NG

Configurer l’authentification Django avec des services tiers

Généralement n’importe quel module d’authentification Djano devrait fonctionner avec Weblate. Il suffit de suivre les instructions du module et de se rappeler de conserver le backend utilisateur de Weblate.

Typiquement l’installation va consister à l’ajout d’un backend d’authentification à AUTHENTICATION_BACKENDS et l’installation d’une app d’authentification (s’il y en une) dans INSTALLED_APPS :

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

INSTALLED_APPS += (
    # Install authentication app here
)

Authentification à deux facteurs

Ajouté dans la version 5.7.

Indication

L’authentification à deux facteurs ajoute un niveau supplémentaire de sécurité à votre compte en demandant plus qu’un simple mot de passe pour se connecter.

Weblate reconnait les seconds facteurs suivants :

Clés de sécurité (WebAuthn)

Both, Passkeys and security keys are supported.

Les clés de passe valident votre identité en utilisant l’empreinte digitale, la reconnaissance faciale, un mot de passe de l’appareil, ou un code PIN puisqu’elles incluent la vérification de l’utilisateur.

Les clés de sécurité sont des informations confidentielles WebAuthn qui ne peuvent être utilisées qu’en tant que second facteur d’authentification et elles ne servent qu’à valider la présence de l’utilisateur.

Authenticator app (TOTP)

Les applications d’authentification et les extensions des navigateurs telles que Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator, etc. génèrent des mots de passe uniques utilisés en tant que second facteur pour vérifier votre identité lorsqu’elle vous est demandée à la connexion.

Codes de récupération

Les codes de récupération peuvent être utilisés pour accéder à votre compte si vous perdez l’accès à votre équipement et que vous ne pouvez plus recevoir les codes d’identification à deux facteurs.

Gardez vos codes de récupération dans un endroit sûr tout comme vos mots de passe. Nous recommandons de les enregistrer avec un gestionnaire de mots de passe tel que Bitwarden, 1Password, Authy, ou Keeper.

Chaque utilisateur peut configurer cela dans Compte et le second facteur vous sera demandé lors de la connexion en complément de la méthode d’authentification existante.

Ceci peut être décidé pour les utilisateurs au niveau du projet (voir Authentification à deux facteurs obligatoire) ou du groupe .

Les privilèges d’un groupe utilisant l’authentification à deux facteurs ne seront pas appliqués aux utilisateurs qui ne l’auront pas configurée.