Configurer DiscourseConnect - le SSO officiel pour Discourse

Discourse · Février 25, 2014, 8:30

DiscourseConnect est une fonctionnalité centrale de Discourse qui vous permet de configurer l’« Authentification Unique (SSO) » pour déléguer entièrement l’inscription et la connexion des utilisateurs de Discourse vers un autre site. Proposé à nos clients hébergés Pro, Business et Entreprise.

(Février 2021) « Discourse SSO » est désormais « DiscourseConnect ». Si vous exécutez une ancienne version de Discourse, les paramètres ci-dessous seront nommés sso_... au lieu de discourse_connect_....

Le problème

De nombreux sites souhaitant s’intégrer à un site Discourse préfèrent conserver toutes les inscriptions d’utilisateurs sur un site distinct. Dans une telle configuration, toutes les opérations de connexion doivent être déléguées à ce site différent.

Que faire si je souhaite utiliser le SSO en conjonction avec une authentification existante ?

L’objectif de DiscourseConnect est de remplacer l’authentification de Discourse. Si vous souhaitez ajouter un nouveau fournisseur, consultez les plugins existants tels que : Discourse VK Authentication (vkontakte)

Activer DiscourseConnect

Pour activer DiscourseConnect, vous devez remplir trois paramètres :

enable_discourse_connect : doit être activé, c’est l’interrupteur global.
discourse_connect_url : l’URL externe vers laquelle les utilisateurs seront redirigés lorsqu’ils tenteront de se connecter.
discourse_connect_secret : une chaîne secrète utilisée pour hacher les charges utiles SSO. Cela garantit que les charges utiles sont authentiques.

Une fois enable_discourse_connect défini sur true :

Cliquer sur la connexion ou sur l’avatar vous redirigera vers /session/sso, qui redirigera ensuite les utilisateurs vers discourse_connect_url avec une charge utile signée.
Les utilisateurs ne pourront pas « modifier le mot de passe ». Ce champ est supprimé du profil utilisateur.
Les utilisateurs ne pourront plus utiliser l’authentification Discourse (nom d’utilisateur/mot de passe, Google, etc.).

Que faire si vous cochez cette option par erreur ?

Voir : Log back in as admin after locking yourself out with read-only mode or an invalid SSO configuration

Implémenter DiscourseConnect sur votre site

Discourse utilise les adresses e-mail pour mapper les utilisateurs externes aux utilisateurs Discourse et suppose que les e-mails externes sont sécurisés. SI VOUS NE VALIDEZ PAS LES ADRESSES E-MAIL AVANT DE LES ENVOYER À DISCOURSE, VOTRE SITE SERA EXTRÊMEMENT VULNÉRABLE !

Alternativement, si vous insistez pour envoyer des e-mails non validés, ASSUREZ-VOUS de définir require_activation=true. Cela forcera la validation de tous les e-mails par Discourse. NOUS DÉCONSEillons FORTEMENT CETTE PRATIQUE. Si vous choisissez de procéder avec ce paramètre activé, vous assumez un risque considérable.

Discourse redirigera les clients vers discourse_connect_url avec une charge utile signée (par exemple, si discourse_connect_url est https://somesite.com/sso) :

Vous recevrez du trafic entrant avec la structure suivante :

https://somesite.com/sso?sso=PAYLOAD&sig=SIG

La charge utile est une chaîne encodée en Base64 comprenant un nonce et un return_sso_url. La charge utile est toujours une chaîne de requête valide.

Par exemple, si le nonce est ABCD, la charge utile brute sera :

nonce=ABCD&return_sso_url=https%3A%2F%2Fdiscourse_site%2Fsession%2Fsso_login. Cette charge utile brute est encodée en base 64.

Le point de terminaison appelé doit :

Valider la signature : s’assurer que le HMAC-SHA256 de PAYLOAD (en utilisant discourse_connect_secret comme clé) est égal à sig (sig sera encodé en hexadécimal).
Effectuer l’authentification requise.
Créer une nouvelle charge utile encodée en URL contenant au moins nonce, email et external_id. Vous pouvez également fournir des données supplémentaires. Voici la liste de toutes les clés que Discourse comprend :
- nonce doit être copié depuis la charge utile d’entrée.
- email doit être une adresse e-mail vérifiée. Si l’adresse e-mail n’a pas été vérifiée, définissez require_activation sur « true ».
- external_id est une chaîne unique pour l’utilisateur qui ne changera jamais, même si son e-mail, son nom, etc. changent. La valeur suggérée est le numéro de ligne « id » de votre base de données.
- username deviendra le nom d’utilisateur sur Discourse si l’utilisateur est nouveau ou si SiteSetting.auth_overrides_username est défini.
- name deviendra le nom complet sur Discourse si l’utilisateur est nouveau ou si SiteSetting.auth_overrides_name est défini.
- avatar_url sera téléchargé et défini comme avatar de l’utilisateur si l’utilisateur est nouveau ou si SiteSetting.discourse_connect_overrides_avatar est défini.
- avatar_force_update est un champ booléen. S’il est défini sur true, il forcera Discourse à mettre à jour l’avatar de l’utilisateur, que avatar_url ait changé ou non.
- bio deviendra le contenu de la biographie de l’utilisateur si l’utilisateur est nouveau, si sa biographie est vide ou si SiteSetting.discourse_connect_overrides_bio est défini.
- title définira le titre de l’utilisateur.
- website définira le site web de l’utilisateur sur son profil.
- location définira la localisation de l’utilisateur sur son profil.
- profile_background_url sera téléchargé et défini comme arrière-plan du profil de l’utilisateur si l’utilisateur est nouveau ou si SiteSetting.discourse_connect_overrides_profile_background est défini.
- card_background_url sera téléchargé et défini comme arrière-plan de la carte de l’utilisateur si l’utilisateur est nouveau ou si SiteSetting.discourse_connect_overrides_card_background est défini.
- locale définira la localisation de l’utilisateur si l’utilisateur est nouveau et si SiteSetting.allow_user_locale est activé.
- locale_force_update est un champ booléen. S’il est défini sur true avec locale, il forcera la mise à jour de la localisation pour les utilisateurs existants (nécessite SiteSetting.allow_user_locale).
- Les champs booléens supplémentaires (« true » ou « false ») sont : admin, moderator, suppress_welcome_message, logout.
Encoder la charge utile en Base64.
Calculer un hachage HMAC-SHA256 de la charge utile en utilisant discourse_connect_secret comme clé et la charge utile encodée en Base64 comme texte.
Rediriger vers l’URL return_sso_url avec les paramètres de requête sso et sig (http://discourse_site/session/sso_login?sso=payload&sig=sig).

Discourse validera que le nonce est valide. S’il l’est, il l’expirera immédiatement afin qu’il ne puisse pas être réutilisé. Ensuite, il tentera de :

Connecter l’utilisateur en recherchant un external_id déjà associé dans le modèle SingleSignOnRecord.
Connecter l’utilisateur en utilisant l’e-mail fourni (en mettant à jour l’external_id) (sauf si require_activation = true).
Créer un nouveau compte pour l’utilisateur en fournissant (e-mail, nom d’utilisateur, nom) et en mettant à jour l’external_id.

Problèmes de sécurité

Le nonce (jeton à usage unique) expirera automatiquement après 30 minutes. Cela signifie que dès que l’utilisateur est redirigé vers votre site, il dispose de 30 minutes pour se connecter ou créer un nouveau compte.

Le protocole est sûr contre les attaques par rejeu car le nonce ne peut être utilisé qu’une seule fois. Le nonce est lié à la session du navigateur actuelle pour se protéger contre les attaques CSRF.

Spécifier l’appartenance aux groupes

Si l’option discourse connect overrides groups est spécifiée, Discourse prendra en compte la liste séparée par des virgules des groupes passés dans groups.

Outre groups, vous pouvez également spécifier l’appartenance aux groupes dans votre charge utile SSO en utilisant les attributs add_groups et remove_groups, indépendamment de l’option discourse connect overrides groups.

add_groups est une liste séparée par des virgules de noms de groupes dont nous nous assurerons que l’utilisateur est membre.
remove_groups est une liste séparée par des virgules de noms de groupes dont nous nous assurerons que l’utilisateur n’est pas membre.

Implémentation de référence

Discourse contient une implémentation de référence de la classe SSO :

github.com/discourse/discourse

lib/discourse_connect_base.rb

main

# frozen_string_literal: true

class DiscourseConnectBase
  class ParseError < RuntimeError
  end

  class PayloadParseError < ParseError
  end

  class SignatureError < ParseError
  end

  ACCESSORS = %i[
    add_groups
    admin
    avatar_force_update
    avatar_url
    bio
    card_background_url
    confirmed_2fa

This file has been truncated. show original

Une implémentation triviale serait :

class DiscourseSsoController < ApplicationController
  def sso
    secret = "MY_SECRET_STRING"
    sso = DiscourseApi::SingleSignOn.parse(request.query_string, secret)
    sso.email = "user@email.com"
    sso.name = "Bill Hicks"
    sso.username = "bill@hicks.com"
    sso.external_id = "123" # identifiant unique pour chaque utilisateur de votre application
    sso.sso_secret = secret

    redirect_to sso.to_url("http://l.discourse/session/sso_login")
  end
end

Transition vers et depuis l’authentification unique.

Tant que le paramètre require_activation n’est pas défini sur true dans la charge utile de la requête, le système fait confiance aux e-mails fournis par le point de terminaison SSO. Cela signifie que si vous aviez un compte existant par le passé sur Discourse avec DiscourseConnect désactivé, DiscourseConnect le réutilisera simplement et évitera de créer un nouveau compte.

Si vous désactivez DiscourseConnect, les utilisateurs pourront réinitialiser leurs mots de passe et retrouver l’accès à leurs comptes.

Exemple concret :

Compte tenu des paramètres suivants :

Domaine Discourse : http://discuss.example.com
URL DiscourseConnect : http://www.example.com/discourse/sso
Secret DiscourseConnect : d836444a9e4084d5b224a60c208dce14
E-mail validé : Non (ajoutez require_activation=true à la charge utile)

Tentative de connexion de l’utilisateur

Un nonce est généré : cb68251eefb5211e58c00ff1395f0c0b
Une charge utile brute est générée : nonce=cb68251eefb5211e58c00ff1395f0c0b
La charge utile est encodée en Base64 : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI=
La charge utile est encodée en URL : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D
Un HMAC-SHA256 est généré sur la charge utile encodée en Base64 : 1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471

Enfin, le navigateur est redirigé vers :

http://www.example.com/discourse/sso?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D&sig=1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471

À l’autre bout

La charge utile est validée à l’aide de HMAC-SHA256. Si la signature ne correspond pas, le processus s’arrête.
En inversant les étapes ci-dessus, le nonce est extrait.

L’utilisateur se connecte :

name: sam
external_id: hello123
email: test@test.com
username: samsam
require_activation: true

Une charge utile non signée est générée :

nonce=cb68251eefb5211e58c00ff1395f0c0b&name=sam&username=samsam&email=test%40test.com&external_id=hello123&require_activation=true

L’ordre n’a pas d’importance, les valeurs sont encodées en URL.

La charge utile est encodée en Base64 :

bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ==

La charge utile est encodée en URL :

bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D

La charge utile encodée en Base64 est signée :

3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

Le navigateur redirige vers :

http://discuss.example.com/session/sso_login?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D&sig=3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

Synchronisation des enregistrements DiscourseConnect

Vous pouvez utiliser le point de terminaison POST /admin/users/sync_sso pour synchroniser un enregistrement DiscourseConnect. Passez-lui le même enregistrement que vous passeriez au point de terminaison DiscourseConnect ; le nonce n’a pas d’importance.

Si vous appelez admin/users/sync_sso depuis un autre site, vous devrez inclure une api_key admin valide et un api_username valide dans les en-têtes de la requête. Consultez Sync DiscourseConnect user data with the sync_sso route pour plus de détails sur la structure de la requête.

Effacer les enregistrements DiscourseConnect

Si vos valeurs external_id provenant de votre fournisseur DiscourseConnect ont changé (peut-être avez-vous modifié l’algorithme de génération, peut-être s’agit-il d’un point de terminaison différent), vous pouvez supprimer en toute sécurité tous les enregistrements existants en utilisant la console Rails :

SingleSignOnRecord.destroy_all

Déconnexion des utilisateurs

Vous pouvez utiliser le point de terminaison POST /admin/users/{USER_ID}/log_out pour déconnecter n’importe quel utilisateur du système si nécessaire.

Pour configurer le point de terminaison vers lequel Discourse redirige lors de la déconnexion, recherchez le paramètre logout redirect. Si aucune URL n’est définie ici, vous serez redirigé vers l’URL configurée dans discourse connect url.

Rechercher des utilisateurs par `external_id`

Les données de profil utilisateur peuvent être consultées via le point de terminaison /users/by-external/{EXTERNAL_ID}.json. Cela retournera une charge utile JSON contenant les informations de l’utilisateur, y compris le user_id qui peut être utilisé avec le point de terminaison log_out.

Implémentations existantes

Le gem discourse_api peut être utilisé pour le SSO. Consultez le code SSO dans son répertoire d’exemples pour voir une implémentation de base.
Notre plugin WordPress facilite la configuration du SSO entre WordPress et Discourse. Les détails sur sa configuration se trouvent dans l’onglet SSO de la page des options du plugin.

Travaux futurs

Nous souhaitons rassembler davantage d’implémentations de référence pour le SSO sur d’autres plateformes. Si vous en avez une, veuillez publier dans la catégorie Dev / SSO.

Fonctionnalités avancées

Vous pouvez transmettre des champs personnalisés pour l’utilisateur en préfixant le nom du champ par custom. Par exemple, custom.user_field_1 peut être utilisé pour définir la valeur de UserCustomField dont le nom est user_field_1.
Vous pouvez transmettre avatar_url pour remplacer l’avatar de l’utilisateur (SiteSetting.discourse_connect_overrides_avatar doit être activé). Les avatars sont mis en cache, donc passez avatar_force_update=true pour forcer leur mise à jour si l’URL est identique. Pour l’instant, vous ne pouvez pas transmettre une URL vide pour désactiver l’avatar des utilisateurs.
Par défaut, le message de bienvenue est envoyé à tous les nouveaux utilisateurs créés via SSO. Si vous souhaitez le supprimer, vous pouvez passer suppress_welcome_message=true.
Pour configurer votre instance Discourse en tant que fournisseur DiscourseConnect, consultez : Utiliser DiscourseConnect comme fournisseur d’identité.

Dépannage de votre fournisseur DiscourseConnect

Pour faciliter le débogage de DiscourseConnect, vous pouvez activer le paramètre du site verbose_discourse_connect_logging. En activant ce paramètre, des diagnostics détaillés apparaîtront dans YOURSITE.com/logs. Assurez-vous de cocher la case warnings en bas de YOURSITE.com/logs.

Nous enregistrerons un avertissement dans les journaux avec un vidage complet de la charge utile SSO :

Chaque fois que le processus DiscourseConnect est lancé, nous enregistrerons un avertissement dans le journal avec un vidage complet de la charge utile DiscourseConnect.
Chaque fois qu’un utilisateur échoue à compléter DiscourseConnect (en raison de l’expiration du nonce ou d’un blocage IP).

Besoin d’automatiser les inscriptions d’utilisateurs ? Consultez Auto-provisioning user accounts when SSO is enabled

dennisjbr · Août 30, 2024, 10:19

Bonjour, j’ai du mal à trouver, mais quel protocole utilise-t-il ? Est-ce que l’on suppose que c’est oauth2 ? Les paramètres ne semblent pas correspondre, et j’obtiens une erreur du fournisseur qui semble accepter un paramètre sso= ? Aidez-moi !

Merci

simon · Août 31, 2024, 10:49

DiscourseConnect est l’implémentation de Discourse du SSO. Il n’utilise pas de protocole standard.

Si cela ne vous dérange pas de regarder du code PHP, il existe un exemple d’implémentation ici : wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub.

Oui, cela ne fonctionnera pas. Si vous avez un fournisseur OAuth2 que vous souhaitez utiliser pour authentifier les utilisateurs, jetez un œil au plugin Discourse OAuth2 Basic.

dennisjbr · Août 31, 2024, 6:26

Merci @simon. Le code PHP est-il également un fournisseur et non un consommateur ? J’ai également vu un fournisseur OIDC qui pourrait fonctionner et aussi un fournisseur « intermédiaire » dans la section des plugins.

Si le fournisseur SSO n’est pas standard, à qui/quoi est-il destiné s’il ne fonctionne pas bien avec les autres ?

Merci encore !

simon · Août 31, 2024, 9:30

Le code que j’ai lié sert à utiliser WordPress comme fournisseur d’authentification pour Discourse.

Le plugin WordPress permet également à WordPress d’être utilisé comme client DiscourseConnect : wp-discourse/lib/sso-client at main · discourse/wp-discourse · GitHub.

Je ne suis pas sûr de la motivation derrière l’ajout d’une implémentation SSO personnalisée à Discourse. Je suppose qu’il y avait une raison commerciale.

L’un des avantages est qu’il permet d’intégrer étroitement un site externe à Discourse. Par exemple, tous les attributs utilisateur listés ici peuvent être synchronisés avec Discourse pendant le processus d’authentification : discourse/lib/discourse_connect_base.rb at 7b89fdead98606d4f47ceb0a1d240d0f6e5f589e · discourse/discourse · GitHub.

Il permet également d’utiliser des sites qui ne sont pas configurés pour être des fournisseurs OAuth2 ou OpenID Connect pour authentifier les utilisateurs sur Discourse.

L’inconvénient est qu’il nécessite d’ajouter du code personnalisé sur le site du fournisseur d’authentification.

eric_wa · Septembre 10, 2024, 8:11

Salut, je suis curieux de savoir quels sont les problèmes liés à la non-vérification des adresses e-mail sur un site externe qui fournit le SSO. Est-ce simplement que cela permet le spam automatisé ? Ou y a-t-il d’autres considérations ? Pourquoi n’est-il pas recommandé que Discourse gère la vérification des e-mails si le site externe ne le fait pas ?

Merci pour tout éclairage supplémentaire.

simon · Septembre 12, 2024, 5:24

Le pire scénario dont j’ai connaissance nécessite ces conditions :

les adresses e-mail ne sont pas vérifiées sur le site externe
require_activation=true n’est pas défini dans la charge utile SSO
il existe des comptes existants sur le site Discourse qui n’ont pas de SingleSignOnRecord associé (le propriétaire du compte ne s’est jamais connecté à Discourse avec SSO)

Dans ce cas, quelqu’un pourrait s’inscrire sur le site externe en utilisant l’adresse e-mail d’un utilisateur Discourse qui ne s’est jamais connecté avec SSO. Cela permettrait au compte non vérifié du site externe de prendre le contrôle du compte Discourse utilisant la même adresse e-mail. Ce serait particulièrement préoccupant s’il s’agissait d’un compte administrateur sur Discourse.

Il est recommandé que Discourse gère la vérification des e-mails si le site externe ne le fait pas :

Il y a cependant quelques raisons pour lesquelles il est préférable de gérer la vérification des e-mails sur le site externe :

forcer les utilisateurs à recevoir l’e-mail de confirmation de Discourse ajoute une certaine friction lorsque les utilisateurs tentent de se connecter pour la première fois à Discourse. (Réaliste, cette friction doit se produire quelque part - soit du côté de Discourse, soit du côté du site externe.)
Discourse ne fera pas correspondre les comptes Discourse existants aux connexions externes en fonction de l’adresse e-mail si require_activation est défini sur true dans la charge utile SSO. C’est un problème si vous activez DiscourseConnect après que certains comptes ont été créés sur Discourse en s’inscrivant avec un nom d’utilisateur/mot de passe. C’est aussi un problème si, pour une raison quelconque, vous devez un jour supprimer les entrées SingleSignOnRecord sur Discourse. Discourse ne créera pas automatiquement de nouvelles entrées SingleSignOnRecord lorsque les utilisateurs tenteront de se reconnecter à Discourse.

eric_wa · Septembre 12, 2024, 3:07

Merci, @simon - c’est très utile !

GregorSondermeier · Décembre 17, 2024, 12:53

Bonjour, j’ai une question concernant le champ groups dans la charge utile SSO.

Les groupes automatisés (comme les administrateurs, les modérateurs et les niveaux de confiance) seront-ils également écrasés ? Ou seront-ils conservés ?

Firepup650 · Décembre 17, 2024, 1:02

Non ! En supposant que la description de ce paramètre soit correcte, cela n’affectera que les groupes manuels.

GregorSondermeier · Décembre 18, 2024, 6:33

Vous savez quoi… Je n’ai pas vu le mot « manuel » dans la description. Ça semble prometteur pour mon cas d’utilisation, je vais essayer et je vous dirai.

probablykasper · Décembre 21, 2024, 7:24

Lorsque j’ai lu ceci, j’ai cru que je devais générer la signature directement à partir de la charge utile encodée en base64. Je n’avais pas réalisé qu’il fallait la générer à partir des octets UTF-8. Cela pourrait-il être clarifié ?

martyn_thomas · Décembre 26, 2024, 1:29

J’ai joué avec DiscourseConnect - la documentation est excellente, merci.
Cependant, j’ai rencontré quelques obstacles pour lesquels j’espère obtenir de l’aide/des éclaircissements.

Nous voulons que les utilisateurs puissent se connecter à WordPress en utilisant leur connexion Discourse (cela fonctionne bien ) - cependant.

Est-il possible de créer un utilisateur WordPress via l’inscription Discourse (lorsqu’un utilisateur crée un compte utilisateur Discourse, il crée automatiquement un compte/profil WordPress pour lui afin qu’il puisse se connecter à WordPress)
Est-il possible de synchroniser les groupes d’utilisateurs WordPress et les groupes Discourse.
Si un utilisateur a un compte utilisateur WordPress et Discourse, DiscourseConnect est capable de les joindre - mais ne donne pas au compte WordPress les groupes d’utilisateurs des groupes Discourse du même nom, et vice versa (et qu’en est-il si les groupes n’ont pas le même nom - comment puis-je dire à DiscourseConnect de donner le groupe d’utilisateurs ‘Groupe de test’ lorsque l’utilisateur a le groupe Discourse ‘Groupe pour tester des choses’ ?

Qu’est-ce qui me manque ?

Jagster · Décembre 26, 2024, 3:25

Je ne connais pas la réponse, mais…

Soyez prudent avec ça. C’est quelque chose d’illégal et considéré comme une mauvaise pratique (en dehors des propriétaires de sites, bien sûr ) car cela se produirait sans le consentement et la connaissance de l’utilisateur, et en même temps les données seraient déplacées ailleurs.

Bien sûr, c’est un peu une zone grise et, fondamentalement, Google fait cela, par exemple.

Mais… pourquoi ? Limitez la connexion uniquement à Discourse SSO côté WordPress et redirigez les utilisateurs vers Discourse pour la création de compte et c’est tout. Mais à ma connaissance, vous ne pouvez pas synchroniser les comptes d’utilisateurs automatiquement dès la sortie de la boîte. Et pourquoi le feriez-vous, car avec le SSO, cela se produit quand un utilisateur en a besoin.

martyn_thomas · Décembre 26, 2024, 4:06

Dans notre scénario (en tant qu’organisation membre)

Wordpress est utilisé pour gérer les abonnements, acheter des articles sur la boutique Wordpress, et nous utilisons les Groupes d’utilisateurs pour gérer ce qu’un membre peut faire dans l’organisation
Discourse est notre forum/communauté en ligne et nous utilisons les Groupes pour contrôler les zones de Discourse auxquelles un utilisateur a accès)

Actuellement, un nouveau membre doit créer un compte Wordpress (et configurer son abonnement, etc.) et également créer un compte Discourse, et les Groupes d’utilisateurs-Groupes Discourse sont gérés/synchronisés manuellement.

J’essaie de trouver une solution où un nouvel utilisateur effectue une seule configuration pour créer les deux comptes, et les Groupes d’utilisateurs-Groupes Discourse sont synchronisés automatiquement - je suis sûr que je peux résoudre la synchronisation des groupes avec des API, etc. C’est la configuration multi-comptes utilisateur que j’essaie de résoudre/éviter.

simon · Décembre 27, 2024, 8:06

Il semble que vous utilisiez Discourse comme fournisseur SSO pour WordPress. Cette approche est décrite ici : Utiliser Discourse comme fournisseur d’identité (SSO, DiscourseConnect). Le plugin Discourse WordPress offre des options pour utiliser WordPress comme fournisseur SSO pour Discourse, ou pour utiliser Discourse comme fournisseur d’identité pour WordPress. Utiliser le même nom pour les deux approches entraîne une certaine confusion.

Je serais tenté d’utiliser WordPress comme fournisseur d’identité dans ce cas. Avec cette approche, les utilisateurs créeront des comptes sur votre site WordPress, puis se connecteront à Discourse avec leurs identifiants WordPress. Une chose à savoir avec cette approche est que cela signifie que les utilisateurs ne pourront se connecter à Discourse que via WordPress, il ne sera pas possible de créer un compte Discourse sans avoir déjà un compte WordPress. Je pense que c’est la configuration appropriée lors de l’intégration de Discourse avec un site d’adhésion WordPress.

Lorsque WordPress est utilisé comme fournisseur d’identité pour Discourse, il existe quelques fonctions utilitaires qui sont utiles pour définir les appartenances aux groupes Discourse des utilisateurs en fonction de leur activité sur WordPress. Ces fonctions sont décrites ici : Gérer l’appartenance aux groupes dans Discourse avec WP Discourse SSO.

Pour revenir à votre question initiale :

Cela fait un moment que je n’ai pas examiné le code du client DiscourseConnect du plugin WordPress, mais je pense que ce que vous demandez est plus ou moins la manière dont ce code est censé fonctionner. Si un utilisateur a un compte Discourse, il lui suffit de cliquer sur le lien “Se connecter via Discourse” sur WordPress et un compte sera créé pour lui.

Ce serait techniquement possible en utilisant WordPress comme client DiscourseConnect, mais à moins que quelque chose n’ait changé, vous ne pourrez pas utiliser les méthodes add_user_to_discourse_group et remove_user_from_discourse_group décrites dans la documentation que j’ai liée. Vous devriez faire quelque chose comme configurer un Webhook Discourse qui serait déclenché lorsqu’un utilisateur est ajouté à un groupe Discourse, puis ajouter du code sur WordPress pour traiter ce webhook. Pour synchroniser les groupes de WordPress vers Discourse, vous devriez faire un appel API à Discourse pour mettre à jour les groupes d’un utilisateur lorsqu’il y a un changement sur WordPress. Donc, quelque chose qui serait assez facile à réaliser si vous utilisez WordPress comme fournisseur DiscourseConnect pourrait être quelque peu compliqué si vous utilisez WordPress comme client DiscourseConnect.

Jagster · Décembre 27, 2024, 8:48

Sauf si une connexion personnalisée est utilisée, comme c’est généralement le cas avec WooCommerce/memberships/LLM qui affichent ce bouton et forcent l’utilisation du seul SSO Discourse comme fournisseur n’est pas le cas par défaut et nécessite un travail personnalisé.

simon · Décembre 28, 2024, 8:32

Il y a quelques problèmes possibles, l’un lié à la mise en cache et l’autre aux redirections de connexion ajoutées par certains plugins. Ceux qui rencontrent ces problèmes devraient en parler dans la catégorie Support > WordPress. Ils sont généralement faciles à résoudre.

GregorSondermeier · Janvier 9, 2025, 7:54

J’ai complètement oublié de faire mon rapport : en effet, cela fonctionne exactement comme décrit, seuls les groupes manuels sont affectés.

Michael_Liu · Mars 21, 2025, 5:20

Salut @simon,
Je pense que j’ai vraiment besoin d’aide concernant la réponse 404 de mon POC pour cette fonctionnalité SSO. Je travaille sur ce problème depuis une journée entière, mais je n’arrive toujours pas à trouver le problème. J’ai pu :

Activer discourse_connect
Définir discourse_connect_url sur https://localhost:4200/login
Secret discourse-connect : 20’s (1) 1111111111111111111 pour simplifier

Ensuite, sur ma page de connexion de mon application Angular, j’ai envoyé cette requête en suivant le code :

mais j’ai reçu la réponse 404 non trouvée.

Pour ma compréhension, lors de l’envoi d’une requête POST à l’endpoint admin/users/sync_sso, si l’utilisateur n’existait pas dans discourse, il devrait créer un nouvel utilisateur basé sur user_id et email, puis le résultat retourné devrait être un objet utilisateur et non un objet vide avec un code d’état 404.
J’ai également vérifié le journal, il n’a fourni aucune information pertinente pour cette réponse échouée.

Merci d’avance !

Sujet		Réponses	Vues
Use Discourse as an identity provider (SSO, DiscourseConnect) Integrations sso , discourseconnect , how-to	143	50641	Novembre 9, 2024
Configure single sign-on (SSO) with WP Discourse and DiscourseConnect Administrators sso , wordpress , video , discourseconnect , how-to	19	6141	Novembre 24, 2025
Integration into custom auth system where emails are not unique? SSO email	40	1476	Juin 6, 2024
DiscourseConnect Provider Questions WordPress	38	2994	Octobre 5, 2023
Merging existing Discourse and WP user lists WordPress	37	3201	Mai 28, 2019