Vejo esta mensagem ao tentar ativar o Discourse_id no meu sistema de teste (3.6.0.beta2-latest):
enable_discourse_id: Você deve configurar as credenciais do Discourse ID ('discourse_id_client_id' e 'discourse_id_client_secret') antes de ativar esta configuração.
Eu uso um servidor Oauth local para OIDC aqui (keycloak). Talvez os dois métodos estejam interferindo um com o outro??
Não acho que interfira com OIDC, mas se a sua instância não estiver disponível na Internet, o registro de ID não funcionará. O provedor de identidade do Discourse ID tem um mecanismo de verificação para as instâncias do Discourse que iniciam o processo de registro.
A instância de teste está online em forum2.netzwissen.de
Vejo a mesma mensagem em 2 instâncias, nenhuma das quais tem uma conexão OAuth diferente.
Movi isto para um tópico separado… você vê algum erro em /logs na sua instância? Deverá haver mais detalhes lá sobre o que não está a funcionar nos bastidores durante o processo de registo.
Gostaria de entender um pouco mais do lado técnico.
Nas minhas instâncias, uso autenticação OIDC com um provedor de identidade externo (Keycloak 26). O Discourse ID parece muito semelhante; é apenas um servidor IDP diferente hospedado pelo Discourse.org. E as mensagens de erro (ID do cliente e segredo ausentes) também lembram o fluxo OAuth clássico. Isso significa que o Discourse ID será ativado como um caminho de autenticação IDP adicional? Porque só assim seria útil para o meu caso de uso. ???
apenas esta, mas com relativa regularidade, então não tem nada a ver com o tópico.
Mensagem (2 cópias relatadas)
Sidekiq está consumindo muita memória (usando: 503.02M) para 'rpg-foren-app', reiniciando
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
'
Sim, correto, Discourse ID é outro IDP.
@Tealk o erro do sidekiq não está relacionado. Você pode compartilhar o hash do commit da sua instância, por favor?
Certo, aqui: 3.5.1 (c96aeda334)
Ok. Então eu precisaria de um ID de cliente no seu IDP (para o fluxo de acesso público) ou um ID de cliente e um Segredo do cliente (para o fluxo de acesso confidencial). Outra opção: adicione o ID do Discourse como um corretor de identidade externo ao IDP local. Para ambas as variantes, seria necessária um pouco mais de informação 
…
Sim, cada instância do Discourse se registra (nos bastidores) e configura um ID de cliente e um segredo.
Agora que vejo sua instância, vejo erros http/https. Para que o ID funcione, o site deve estar em https. Provavelmente esse é o seu problema.
@Tealk certifique-se de que seu site também esteja funcionando corretamente em https.
Eu não saberia o que poderia melhorar:
O Discourse ID já funciona em fóruns que usam o branch estável? Pensei que o recurso só seria adicionado após o lançamento em agosto.
Ah, de fato, se você estiver no canal stable, @Tealk, terá que esperar pela próxima versão estável para que o Discourse ID esteja disponível para você.
Note também que o DiscourseConnect é um recurso separado.
Ok, então isso é confuso na página de novidades. Seria possível adicionar a partir de qual versão um recurso está incluído?
Esse é um bom ponto. Atualizei o feed Novidades para incluir apenas este item para instâncias que não estão em versão estável (e que possuem o commit em latest que desbloqueia o ID do Discourse). Se você atualizar seu feed Novidades, não deverá mais ver este item em sua instância em versão estável.
Já tenho as configurações em Configurações, a configuração deve estar disponível antes de ser implementada?
A configuração do site enable_discourse_id não deve estar presente para você. (Certifique-se de não confundi-la com enable_discourse_connect, isso é outra coisa.)
Agora que vejo sua instância, vejo erros http/https. Para que o ID funcione, o site deve estar em https. Este é provavelmente o seu problema.
… interessante, mas não entendo por quê. Talvez tenhamos uma lacuna conceitual aqui: os contêineres do Discourse estão localizados atrás de um acelerador SSL, acessível apenas via https. Mas isso é para a conexão padrão que vem de “fora” para “dentro”. No caso de uso do OAuth, o contêiner do Discourse inicia a conexão de “dentro” para o IDP, que está “fora”. Não vejo nenhuma opção para configurar essa conexão com o ID do Discourse e forçá-la a ser “https“.
Se eu comparar isso com as configurações clássicas do OIDC usadas para configuração do OAuth com meu próprio IDP: lá temos uma configuração de “Documento de descoberta OpenID Connect”
https://....realms/[realm-name]/.well-known/openid-configuration
Acho que precisamos de algo semelhante para o ID do Discourse para evitar problemas com conexões https ausentes. PS. Minha instância de teste tem 3.6.0.beta2-latest, Commits · discourse/discourse · GitHub
