Hier ist eine Liste von Installationsmethoden: Set up a local Discourse Development Environment?. Ich habe eine Nicht-Docker-Entwicklungsseite (unter Verwendung der Ubuntu-Anleitung). Wenn es für Sie möglich ist, denke ich, dass Sie mit dem Nicht-Docker-Ansatz die besten Ergebnisse erzielen werden. Einer der Gründe, warum ich ihn verwende, ist, dass ich mich nicht mit Netzwerkproblemen für API-Anfragen zwischen Discourse und anderen Anwendungen, die ich lokal entwickle, auseinandersetzen muss. Er ist auch schneller als Docker.
Das sollte es sein. Stellen Sie sicher, dass die Anwendung, auf der Sie die SSO-Payload generieren, den booleschen Wert true nicht in 1 umwandelt. Das ist ein häufiges Problem. Um dies zu umgehen, können Sie alle booleschen Werte in der SSO-Payload auf die Strings \"true\" oder \"false\" setzen. Discourse wird sie korrekt interpretieren. Überprüfen Sie das zuerst, um zu sehen, ob das das Problem ist. Es könnte auch etwas anderes sein. Der Code, der avatar_force_update behandelt, ist ziemlich komplex, aber lesbar: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Bearbeitung: Bezüglich des Problems mit booleschen Werten in der SSO-Payload ist es wohl genauer zu sagen, dass die Umgebung im Prozess der Generierung der SSO-Payload die booleschen Werte true/false in Strings umwandelt. Discourse erwartet die Strings \"true\" oder \"false\", andere Programmierumgebungen gehen möglicherweise anders damit um. Zum Beispiel:
PHP:
wp> strval(true)
=> string(1) "1"
im Gegensatz zu Ruby:
irb(main):001> true.to_s
=> "true"
Python (ich bin mir nicht sicher, wie Discourse damit umgeht):
>>> str(True)
'True'