# Wantrouwen: Discourse als OpenID Connect provider **URL:** https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385 **Category:** Extras **Created:** [29 juni 2021 om 17:24 UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385 "2021-06-29T17:24:42Z") **Posts on this page:** 1 **Showing post:** 12
### Author: ![BrianC](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/brianc/32/487568_2.png) [@BrianC](https://meta.discourse.org/u/BrianC) #### Post date: [1 september 2025 om 03:35 UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/12 "2025-09-01T03:35:15Z")
{“content”:“Ik hoop wat deskundige ogen te werpen op problemen die ik ondervind bij het gebruik van Discourse als SSO-provider.\n\n **Mijn Doel:** Ik ben bezig met het instellen van Discourse om authenticatie af te handelen voor een andere applicatie (LibreChat). Ik gebruik de standaard `DiscourseConnect`-providerfunctionaliteit, waarbij de OIDC-brugservice `distrust` fungeert als de client die communiceert met Discourse.\n\n **Het Probleem:** De SSO-stroom werkt perfect tot de allerlaatste stap. De gebruiker wordt correct omgeleid van mijn app naar Discourse en kan succesvol inloggen met hun Discourse-gegevens. Echter, na het inloggen, worden ze omgeleid naar de startpagina van mijn Discourse-forum (`/`) in plaats van naar de `return_sso_url` die werd verstrekt.\n\n**Waar ik vastloop (Wat ik heb uitgesloten):** Ik heb dit al een tijdje onderzocht en bevestigd dat dit geen eenvoudig configuratiefout is. Ik heb definitief het volgende uitgesloten:\n\n\* **Geheimen:** De `discourse connect provider secrets` zijn correct geconfigureerd. Ik gebruik het platte domein (bijv. `auth.my-site.com`) zonder enig protocol, en de geheime sleutel komt perfect overeen met die in mijn client-service.\n\* **SSO-modus:** Ik heb gecontroleerd of `enable discourse connect provider` is aangevinkt en dat de onjuiste "SSO Client"-instellingen zijn uitgeschakeld.\n\* **Gebruikersbeleid:** Ik heb ervoor gezorgd dat `must_approve_users` is uitgeschakeld en mijn testgebruiker is een beheerder met een volledig geverifieerd e-mailadres.\n\* **Plugins:** Ik heb alle niet-officiële plug-ins van derden uitgeschakeld en de container opnieuw opgebouwd, maar het probleem blijft bestaan.\n\n **Het Belangrijkste Bewijs:** Ik heb twee definitieve bewijsstukken die me verbijsteren:\n\n1. **HAR-bestandanalyse:** Ik heb de volledige netwerkstroom vastgelegd in een HAR-bestand. Het toont aan dat het `POST`-verzoek naar `/session` voor inloggen succesvol is. De server reageert onmiddellijk met een `302 Found`-omleiding, maar de `Location`-header is consequent `/`. Dit bewijst dat Discourse de SSO-omleiding opzettelijk afbreekt.\n2. **Leeg Rails-logboek:** Ik heb vervolgens het `production.log`-bestand binnen de container gevolgd tijdens een inlogpoging. **Er wordt absoluut niets naar het logboek geschreven tijdens dit proces.** Dit vertelt me dat Discourse dit niet als een fout beschouwt; het is een doelbewuste, stille actie.\n\n **Mijn Vraag:** Gezien het feit dat de inlogpoging succesvol is, maar de omleiding onjuist is en er geen fouten in de logboeken staan, welk intern Discourse-beleid, pre-flight check of verborgen instelling zou er dan voor kunnen zorgen dat de `return_sso_url` wordt genegeerd en in plaats daarvan naar de startpagina wordt omgeleid? Ik heb het gevoel dat ik alle standaardinstellingen heb uitgeput.\n\nAlvast bedankt voor alle ideeën!”,“target\_locale”:“nl”} --- _[View the full topic](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385)._