C’è un elenco di metodi di installazione qui: Set up a local Discourse Development Environment?. Ho un sito di sviluppo non-Docker (usando la guida Ubuntu). Se è possibile per te farlo, penso che otterrai i migliori risultati con l’approccio non-Docker. Uno dei motivi per cui lo uso è per non dover affrontare problemi di rete per le richieste API tra Discourse e altre applicazioni che sto sviluppando localmente. È anche più veloce di Docker.
Dovrebbe esserlo. Assicurati che l’applicazione su cui stai generando il payload SSO non stia convertendo il valore booleano true in 1. Questo è un problema comune. Per aggirarlo, puoi impostare qualsiasi valore booleano nel payload SSO sulle stringhe \"true\" o \"false\". Discourse li interpreterà correttamente. Controlla prima questo per vedere se è il problema. Potrebbe essere qualcos’altro. Il codice che gestisce avatar_force_update è piuttosto complesso, ma leggibile: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Modifica: Per il problema dei valori booleani nel payload SSO, immagino sia più accurato dire che nel processo di generazione del payload SSO, l’ambiente convertirà i valori booleani true/false in stringhe. Discourse si aspetta che le stringhe siano \"true\" o \"false\", altri ambienti di programmazione potrebbero gestirli diversamente. Ad esempio:
PHP:
wp> strval(true)
=> string(1) "1"
invece di Ruby:
irb(main):001
=> "true"
Python (non sono sicuro di come Discourse gestisca questo):
>>> str(True)
'True'