{“content”:“Ik hoop wat deskundige ogen te werpen op problemen die ik ondervind bij het gebruik van Discourse als SSO-provider.\n\nMijn 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\nHet 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\nWaar 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\nHet 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\nMijn 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”}