Olá, estou integrando o Discourse com um site de comunidade onde os membros já podem “bloquear” uns aos outros. Então, quando um membro do meu site fizer o SSO no Discourse, gostaria de passar também a lista de external_id bloqueados. Acredito que esses valores possam simplesmente ser inseridos no campo “Usuários silenciados” do lado do Discourse…
E, se não for possível, para realizar essa funcionalidade, parece que terei que configurar um webhook e, ao receber um evento user_logged_in do webhook, posso usar a API do Discourse para passar a lista de usuários silenciados… está correto? (E, se sim: onde está essa chamada na API? Não consegui encontrá-la!)
Sim, isso soa um pouco semelhante ao que outras extensões SSO já possuem. É bastante raro precisar disso, então estou em dúvida sobre adicionar isso ao protocolo ou não.
O webhook funcionará; você será chamado no login e, em seguida, poderá fazer uma segunda chamada ao Discourse para sincronizar a lista por meio da nossa API.
Olá, Sam. Sim, para o meu problema imediato, vou apenas responder ao evento de webhook user_logged_in — sem problema. Obrigado por isso.
E entendo sua perspectiva sobre o que pode ser transmitido no SSO. À medida que continuo a integrar profundamente o Discourse ao meu site, estou entendendo melhor como vocês decidiram implementar o SSO. Funciona bem agora, mas na verdade acho que poderia ser interessante consolidar todas as caixas de seleção “SSO overrides…” em uma caixa de seleção geral do tipo “SSO gerencia todos os atributos do usuário” (ou algo assim).
A ideia seria que, se eu ativar essa caixa de seleção global de SSO, a única coisa com que precisaria me preocupar em manter a consistência seria o external_id: garantindo ao Discourse que ele será sempre único, identificará sempre o mesmo usuário e nunca mudará. Uma vez que isso esteja em vigor, eu poderia transmitir todos os campos que quisesse na solicitação de SSO e carregar o usuário completamente a partir do meu banco de dados.
sobre adicionar isso ao protocolo ou não.