Thanks for this post, which was invaluable in setting up a recent project, which required Salesforce login.
In our case, the Salesforce app was a Community, which meant we had to change some of the details above. I’m posting on this old thread in case it helps anyone else. It nearly broke my brain for a whole day.
However we still had problems with 403 Forbidden errors, which were plain unstyled HTML and didn’t look very much like a Discourse error to me, which led to much debugging of Salesforce and gnashing of teeth. But the problem was in Discourse.
Forbidden
You don’t have permission to access this resource.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
Although the redirect to Callback URL seemed to be working, the browser console registered authentication failures. In the end it was the unsetoauth2 callback user id path which was the cause of the authentication failure. Setting it to id fixed everything.
Vielen Dank für die Richtlinien. Wir konnten uns erfolgreich mit Salesforce authentifizieren, sind jedoch auf ein Problem gestoßen. Unsere SF-Objekte/Felder werden anscheinend nicht erfolgreich an Discourse übergeben. Direkt nach einer erfolgreichen SF-Anmeldung auf Discourse scheint Discourse den Benutzer als neuen Benutzer zu behandeln und fragt nach Benutzername, E-Mail und Namen, obwohl diese Werte eigentlich aus den OAuth2-JSON-Feldern name, email und username stammen sollten.
Könnten Sie uns bitte helfen, das JSON-Format für die in der OAuth2-Plugin verwendeten SF-Objekte/Felder zu erfahren? Wir haben object.field, object_field und einfach field ausprobiert. Es scheint zwar keine Fehlermeldung zu geben, aber es werden trotzdem keine Daten von Salesforce an Discourse über JSON übergeben, um die Anmeldung als keine neue Discourse-Benutzeranmeldung zu erkennen.
Danke für die Info @sonny.mendoza – ich habe sie in die Anweisungen am Anfang dieses Themas aufgenommen, damit sie auch anderen Leuten in Zukunft helfen kann