Não tenho uma instalação local do Discourse no momento, então não tenho certeza do quanto posso ajudar.
A resposta 404 me faz pensar se o Discourse Connect está realmente habilitado no seu site Discourse:
Parece que você está testando isso com um aplicativo Angular local e um site Discourse em produção. Eu esperaria que isso ainda funcionasse, mas possivelmente está causando um problema. Você definitivamente deve ser capaz de obter algum tipo de resposta além de um 404.
@simon obrigado pela sua resposta,
isso havia sido confirmado várias vezes por mim,
e eu também tenho um site de teste de produção que estava hospedado no domínio pai deste site do Discourse. Se você puder dar uma olhada neste [link removido]
para testar o fluxo de produção, atualizei a URL do Discourse Connect para “https://domainsite.com/login”, sinta-se à vontade para fazer login com o provedor do Google e fazer um teste. No log do console de inspeção, você verá o erro e a resposta que imprimi, que é 404.
já que estou apenas fazendo o POC, se você não se importar, pode me deixar seu e-mail para que eu possa te definir como administrador para investigar as configurações do meu site do Discourse de perto. Novamente, agradeço muito seu tempo e ajuda.
A única parte sobre a qual não tenho certeza é o sig e o sso, estou fazendo corretamente pelo código?
Além dessa parte, a chave da API, tentei ambas, gerando para todos e apenas para o sistema, os resultados são os mesmos.
Se possível, por favor, forneça um exemplo funcional para Postman ou código baseado em Angular.
Perdi isso quando olhei pela primeira vez a captura de tela do seu código:
mode: 'no-cors'
Não estou familiarizado com aplicativos Angular, mas parece que você está tentando fazer uma solicitação de API autenticada para o Discourse a partir do cliente. Não tenho certeza de onde isso acontece no código do Discourse, mas entendo que o Discourse bloqueia solicitações de API de administrador feitas a partir do cliente. Isso ocorre porque não há como fazer a solicitação sem expor a chave da API no cliente. Relacionado a isso, você deve alterar sua chave de API agora.
obrigado por apontar isso,
parece um passo à frente.
Também estou tentando enviar a solicitação do Postman.
Se você acha que o bloqueio do lado do cliente “mode: ‘no-cors’” já que o Discourse se recusou a aceitar a chamada com chaves de API do front-end, então acho que tudo bem enviá-lo do Postman, está correto? mas o resultado é o mesmo
Eu até tentei iniciar um servidor e acionar o servidor para enviar a solicitação com a chave de API no lado do servidor, o que dá o mesmo resultado, me faz sentir que estou perdendo algumas configurações no site do Discourse.
É uma boa ideia fazer isso funcionar a partir do Postman, ou mesmo da linha de comando. Pela captura de tela que você postou, parece que você tem o api-username e a api-key no corpo da solicitação. Esses parâmetros precisam estar no cabeçalho da solicitação. O corpo da solicitação deve conter os pares de chave/valor sig e sso. Se ajudar, veja como o plugin WP Discourse lida com isso: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub .
Uau! Aí vamos nós,
agora está funcionando!
1000 obrigado @simon
o problema foi exatamente como você mencionou:
sso e sig devem ser os únicos dois pares de chaves no corpo
api-key e api-username devem estar nos cabeçalhos
Como isso se comportará se eu ativar isso em um site que não usa external_id atualmente? Ele conseguirá fazer login de usuários com base apenas em seus e-mails?
De forma mais geral, como email e external_id são os 2 campos obrigatórios na carga útil, você poderia esclarecer como eles são usados no lado do discourse (ao receber a carga útil do site de autenticação) para descobrir qual conta de usuário fazer login?
external_id foi associado ao e-mail durante a criação do usuário, ele usará o e-mail e, em seguida, associará o external_id a este e-mail para logins futuros?email e external_id (cada um associado a uma conta de discourse diferente), ele usará external_id ou email para descobrir qual usuário fazer login? Ou gerará um erro?Obrigado!
Eu acho que sua principal dúvida é sobre o campo external_id. Você precisa definir um campo external_id no payload do DiscourseConnect. O valor do campo deve ser uma string associada ao usuário que nunca mudará. Presumo que seu aplicativo tenha uma tabela de usuários. A chave primária para a entrada de um usuário nessa tabela seria um bom valor para o campo external_id.
Se um usuário criou uma conta no Discourse antes de você adicionar a autenticação DiscourseConnect do seu site, na primeira vez que ele fizer login no Discourse através do DiscourseConnect, o Discourse tentará encontrar o usuário com base no endereço de e-mail que está no payload do DiscourseConnect. Após encontrar o usuário, um registro será adicionado ao banco de dados do Discourse contendo o external_id do payload do DiscourseConnect. Na próxima vez que o usuário fizer login, ele será encontrado pelo external_id em vez do endereço de e-mail. (Observe que isso não funciona se você definir o parâmetro require_activation no payload do DiscourseConnect como true.)
O Discourse tem bons mecanismos de fallback para a maioria dos casos extremos. Existem problemas relacionados a usuários com várias contas e endereços de e-mail que podem gerar erros. Alguns detalhes sobre como lidar com esses casos estão aqui: Depuração e correção de problemas comuns do DiscourseConnect.
Muito útil, obrigado! Parece que tudo funciona como eu esperava 
Temos usado o DiscourseConnect com o WordPress como provedor com sucesso por vários anos e não alteramos as configurações do Discourse ou do WP. Hoje notei o que acho que é um novo comportamento.
Quando faço logout, ele me levava para a tela de login do WordPress. Agora ele me leva para a tela de login do Discourse. Se eu tentar fazer login com a tela do Discourse, recebo um Erro Desconhecido, mas o ponto é que eu não deveria estar lá - eu deveria estar no login do WP.
Note que tenho logins locais habilitados (não sei por quê, já que estou usando WP). Se eu desabilitar os logins locais e tentar fazer login, ele diz que não há métodos de login disponíveis. Então, acho que ele não gosta da minha conexão WP, mas novamente, eu não alterei as configurações em nenhuma das pontas. Confirmei que o Discourse Connect está habilitado, a URL de conexão está correta e o segredo é o mesmo em ambas as pontas.
Atualizado com 3.5.0.beta5-dev. Também o plugin WP Discourse está atualizado.
acontecendo comigo também, vou mexer nele para ver se encontro o problema.
Nós também estamos usando DiscourseConnect e enfrentando o mesmo problema.
Estamos com ele funcionando há alguns anos e tudo funcionou perfeitamente. atualizado hoje para 3.5.0.beta8-dev [e91024a221]
Basicamente, o callback do sistema sso para a url do discourse adiciona https://discourse.domain.ext/login e temos a mesma tela que @markschmucker
Também notamos que ao clicar no logo do cabeçalho, acessamos https://discourse.domain.ext/ e o login é bem-sucedido (apenas um clique em um botão é necessário)
Parece que na versão anterior o session controller estava se comportando de forma diferente, provavelmente entendendo que a chamada foi iniciada por sso externo e a estava tratando da maneira correta
Notei que no último mês @zogstrip fez algumas alterações que podem estar relacionadas (não 100% certo) ao mau funcionamento
Por enquanto, aplicamos uma solução alternativa no método de callback que adicionava /login à url do discourse e tudo parece funcionar corretamente.
Se estou perdendo alguma coisa, como alguma documentação que dava conselhos sobre uma mudança potencialmente disruptiva nesta parte do código, me avise.
Obrigado a todos pelo apoio
@markschmucker, @jimkleiber e @marco.palumbo vocês têm o mesmo problema destacado em No login methods when using Discourse Connect only?
Se sim, a correção é garantir que a configuração do site “autenticar imediatamente” esteja ativada.
Eu tenho "autenticar imediatamente" ativado.
Obrigado pela sua ajuda com isso @zogstrip. Infelizmente, se eu habilitar o “auth imediatamente”, perco a capacidade de ter uma página de “boas-vindas” para usuários anônimos.
Não parece ser possível remover um nome ou avatar_url usando o DiscourseConnect SSO. Tentei definir os campos como uma string vazia (confirmado, por exemplo, que avatar_url= está sendo incluído no parâmetro sso base64), mas acho que o código ignora campos vazios.
Nomes e imagens são opcionais no meu sistema, mas da forma como isso está funcionando agora, uma vez definidos, eles nunca podem ser desfeitos, apenas substituídos. Alguma chance de eu estar fazendo algo errado? (Se não, talvez isso possa ser corrigido?)
[Edit]: Eu já tinha procurado uma resposta, mas é claro que no segundo em que postei o acima, tentei pesquisar palavras-chave diferentes e encontrei Allow name removal using SSO - #9 by mentalstring. Dei um upvote lá, mas não estou criando muitas esperanças. 
Estou tendo o mesmo problema de redirecionamento de login que @markschmucker, @jimkleiber e @marco.palumbo descrevem acima, que descobri há algumas semanas e sabia que estava funcionando corretamente em algum momento de maio. Ler o que vocês disseram sobre isso acima me convence de que é uma regressão no Discourse introduzida em alguma atualização de maio, porque atingiu todos nós ao mesmo tempo, todos nós tínhamos código SSO funcionando e não compartilhamos nenhum código SSO em comum.
Postei um relatório de bug na esperança de que possamos consertar isso.
O problema de redirecionamento foi corrigido para mim na versão 3.6.0-beta1.
@markschmucker e @marco.palumbo
Parece que isso foi corrigido há algumas semanas e deve estar funcionando corretamente novamente em v3.6.0.beta1.