Je vois ce message lorsque j’essaie d’activer Discourse_id sur mon système de test (3.6.0.beta2-latest) :
enable_discourse_id : Vous devez configurer les identifiants Discourse ID ('discourse_id_client_id' et 'discourse_id_client_secret') avant d'activer ce paramètre.
J’utilise un serveur Oauth local pour OIDC ici (keycloak). Peut-être que les deux méthodes interfèrent l’une avec l’autre ??
Je ne pense pas que cela interfère avec OIDC, mais si votre instance n’est pas disponible sur Internet, l’enregistrement de l’ID ne fonctionnera pas. Le fournisseur d’identité Discourse ID dispose d’un mécanisme de vérification pour les instances Discourse qui initient le processus d’enregistrement.
L’instance de test est en ligne sur forum2.netzwissen.de
Je vois le même message sur 2 instances, dont aucune n’a de connexion OAuth différente.
J’ai déplacé ceci dans un sujet distinct… voyez-vous des erreurs dans /logs sur votre instance ? Cela devrait y afficher plus de détails sur ce qui ne fonctionne pas en coulisses pendant le processus d’inscription.
J’aimerais en comprendre un peu plus du côté technique.
Sur mes instances, j’utilise l’authentification OIDC avec un fournisseur d’identité externe (Keycloak 26). Discourse ID ressemble beaucoup à cela ; c’est juste un serveur IDP différent hébergé par Discourse.org. Et les messages d’erreur (client ID et secret manquants) rappellent également le flux OAuth classique. Cela signifie-t-il que Discourse ID sera activé comme chemin d’authentification IDP supplémentaire ? Parce que ce n’est qu’alors qu’il serait utile pour mon cas d’utilisation. ???
seulement celui-ci, mais relativement régulièrement donc cela n’a rien à voir avec le sujet.
Message (2 copies signalées)
Sidekiq consomme trop de mémoire (utilisation : 503,02 Mio) pour « rpg-foren-app », redémarrage
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
’
Oui, c’est exact, Discourse ID est un autre IDP.
@Tealk l’erreur sidekiq n’est pas liée. Pouvez-vous partager le hash du commit pour votre instance s’il vous plaît ?
3.5.1 (c96aeda334)
Ok. J’aurais alors besoin d’un ID client sur votre IDP (pour le flux d’accès public) ou d’un ID client et d’un secret client (pour le flux d’accès confidentiel). Une autre option : ajouter Discourse ID en tant que courtier d’identité externe à l’IDP local. Pour les deux variantes, un peu plus d’informations seraient nécessaires 
…
Oui, chaque instance Discourse s’enregistre (en coulisses) et configure un ID client et un secret.
Maintenant que je regarde votre instance, je vois des erreurs http/https. Pour que l’ID fonctionne, le site doit être en https. C’est probablement votre problème.
@Tealk assurez-vous que votre site fonctionne également correctement en https.
Je ne saurais dire ce que je pourrais améliorer :
Est-ce que Discourse ID fonctionne déjà sur les forums qui utilisent la branche stable ? Je pensais que la fonctionnalité ne serait ajoutée qu’après la sortie en août.
Ah, en effet, si vous êtes sur le canal stable, @Tealk, vous devrez attendre la prochaine version stable pour que Discourse ID soit disponible pour vous.
Notez également que DiscourseConnect est une fonctionnalité distincte.
D’accord, c’est donc déroutant sur la page des nouveautés. Serait-il possible d’ajouter à partir de quelle version une fonctionnalité est incluse ?
C’est un bon point. J’ai maintenant mis à jour le flux « Nouveautés » pour inclure uniquement cet élément pour les instances qui ne sont pas sur la version stable (et qui ont le commit dans latest qui déverrouille l’ID Discourse). Si vous actualisez votre flux « Nouveautés », vous ne devriez plus voir cet élément sur votre instance en version stable.
J’ai déjà les paramètres dans les paramètres, le paramètre doit-il être disponible avant sa mise en œuvre ?
Le paramètre du site enable_discourse_id ne devrait pas être présent pour vous. (Assurez-vous de ne pas le confondre avec enable_discourse_connect, c’est autre chose.)
Maintenant que je regarde votre instance, je vois des erreurs http/https. Pour que l’ID fonctionne, le site doit être en https. C’est probablement votre problème.
… intéressant, mais je ne comprends pas pourquoi. Peut-être avons-nous une lacune conceptuelle ici : les conteneurs Discourse sont situés derrière un accélérateur SSL, uniquement accessibles via https. Mais c’est pour la connexion standard venant de « l’extérieur » vers « l’intérieur ». Dans le cas d’utilisation OAuth, le conteneur Discourse initie la connexion de « l’intérieur » vers l’IDP qui est « à l’extérieur ». Je ne vois aucune option pour configurer cette connexion à l’ID Discourse et la forcer à être « https ».
Si je compare cela avec les paramètres OIDC classiques utilisés pour la configuration OAuth avec mon propre IDP : nous y avons un paramètre « OpenID Connect discovery document »
https://....realms/[realm-name]/.well-known/openid-configuration
Je pense que nous avons besoin de quelque chose de similaire pour l’ID Discourse afin d’éviter les problèmes de connexions https manquantes. PS. Mon instance de test a la version 3.6.0.beta2-latest, Commits · discourse/discourse · GitHub
