Il y a une liste de méthodes d’installation ici : Set up a local Discourse Development Environment?. J’ai un site de développement non-Docker (en utilisant le guide Ubuntu). Si c’est possible pour vous, je pense que vous obtiendrez les meilleurs résultats avec l’approche non-Docker. L’une des raisons pour lesquelles je l’utilise est de ne pas avoir à gérer les problèmes de réseau pour les requêtes API entre Discourse et d’autres applications que je développe localement. C’est aussi plus rapide que Docker.
Ça devrait l’être. Assurez-vous que l’application sur laquelle vous générez la charge utile SSO ne convertit pas la valeur booléenne true en 1. C’est un problème courant. Pour contourner cela, vous pouvez définir toutes les valeurs booléennes dans la charge utile SSO sur les chaînes \"true\" ou \"false\". Discourse les interprétera correctement. Vérifiez cela d’abord pour voir si c’est le problème. Ça pourrait être autre chose. Le code qui gère avatar_force_update est assez complexe, mais lisible : discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Edit : Pour le problème des valeurs booléennes dans la charge utile SSO, je suppose qu’il est plus exact de dire que dans le processus de génération de la charge utile SSO, l’environnement va convertir les valeurs booléennes true/false en chaînes de caractères. Discourse s’attend à ce que les chaînes soient \"true\" ou \"false\", d’autres environnements de programmation peuvent les gérer différemment. Par exemple :
PHP :
wp> strval(true)
=> string(1) "1"
Contrairement à Ruby :
irb(main):001> true.to_s
=> "true"
Python (je ne suis pas sûr de la façon dont Discourse gère cela) :
>>> str(True)
'True'