Integração em custom auth system onde e-mails não são únicos?

Há uma lista de métodos de instalação aqui: Set up a local Discourse Development Environment?. Tenho um site de desenvolvimento que não usa Docker (usando o guia do Ubuntu). Se for possível para você, acho que você obterá os melhores resultados com a abordagem sem Docker. Uma das razões pelas quais eu o uso é para não ter que lidar com problemas de rede para requisições de API entre o Discourse e outros aplicativos que estou desenvolvendo localmente. É mais rápido que o Docker também.

Deveria ser. Certifique-se de que o aplicativo no qual você está gerando a carga útil do SSO não esteja convertendo o valor booleano true para 1. Esse é um problema comum. Para contornar isso, você pode definir quaisquer valores booleanos na carga útil do SSO para as strings \"true\" ou \"false\". O Discourse os interpretará corretamente. Verifique isso primeiro para ver se é o problema. Pode ser outra coisa. O código que lida com avatar_force_update é um tanto complexo, mas legível: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.

Editar: Para o problema de valores booleanos na carga útil do SSO, acho que é mais preciso dizer que, no processo de geração da carga útil do SSO, o ambiente converterá os valores booleanos true/false em strings. O Discourse espera que as strings sejam \"true\" ou \"false\", outros ambientes de programação podem lidar com elas de forma diferente. Por exemplo:

PHP:

wp> strval(true)
=> string(1) "1"

em oposição a Ruby:

irb(main):001> true.to_s
=> "true"

Python (não tenho certeza de como o Discourse lida com isso):

>>> str(True)
'True'
2 curtidas