Gostaríamos de integrar o Discourse aos nossos sistemas existentes, para remover a dependência do nosso servidor Discord para suporte. Já temos nosso próprio sistema de contas configurado e gostaríamos de reutilizá-lo, se possível, para reduzir o atrito. No entanto, os endereços de e-mail não são obrigatórios para serem exclusivos em nosso caso, apenas os nomes de usuário. Parece que o Discourse se baseia na suposição de que os e-mails serão globalmente exclusivos, o que nos impede de integrar diretamente.
Verifiquei o DiscourseConnect, que parecia promissor, mas afirma:
O Discourse usa e-mails para mapear usuários externos para usuários do Discourse
O que não funcionaria em nosso caso, pois várias contas podem (e usam) o mesmo endereço de e-mail.
Em seguida, analisamos o Discourse OAuth2 Basic, que à primeira vista não exigia um e-mail:
O único atributo obrigatório é id
No entanto, mais tarde, ele ainda menciona a entrada manual de um endereço de e-mail posteriormente, se não for fornecido pela fonte oauth:
Note que omiti o caminho do e-mail: o SoundCloud não fornece um e-mail, então o usuário terá que fornecê-lo e verificá-lo quando se inscrever pela primeira vez no Discourse
O uso do Discourse ainda seria algo viável em nosso caso? Ter os usuários fornecendo manualmente um endereço de e-mail ao fazer login no Discourse pela primeira vez seria aceitável em nosso caso, mas apenas se pudermos desativar a capacidade de usar um endereço de e-mail durante o processo de login real (exigindo o uso apenas do nome de usuário e senha), pois não podemos mapear confiavelmente um e-mail para um usuário exclusivo. Ser capaz de desativar isso completamente do formulário de login removeria o atrito em nosso lado, pois não seria algo que suportaríamos de qualquer maneira, e gostaríamos de impedir que os usuários até mesmo tentassem fazê-lo.
Consideramos isso, mas não tínhamos certeza de como isso afetaria o fluxo do OAuth ou se adicionaria atrito ao cadastro/login. Esse tipo de alteração seria invisível para o usuário, então ele falharia ao fazer login, a menos que insira esse endereço de e-mail modificado. Nosso servidor de contas atual também estaria ciente dessas modificações, então, mesmo que eles inserissem o e-mail modificado, não conseguiríamos encontrá-lo em nossos registros?
Isso também quebraria usuários que já usam aliases de e-mail, não é?
Bem, sim. Claro que seria o caso, e é o que estou visando. Eu estava procurando uma solução que simplesmente proibisse o login com e-mail, deixando os logins com nome de usuário como o único método. Eu ficaria feliz em essencialmente quebrar o suporte de e-mail inteiramente (sem notificações por e-mail, por exemplo) apenas fornecendo e-mails totalmente falsos do servidor oauth. Mas isso cria atrito se a capacidade de usar um e-mail para fazer login ainda estiver disponível, já que os usuários tentariam fazê-lo e falhariam.
Isso essencialmente nos forçaria a rastrear 2 e-mails separados por usuário, o que também não é desejável e, como mencionado por @supermathie, nem sequer é garantido que funcione com todos os provedores, e ainda causa atrito, pois teríamos que informar aos usuários sobre este endereço de e-mail específico do fórum que eles precisam lembrar.
Sim, isso funcionaria tecnicamente. Mas, por razões óbvias, não seria uma solução real para usar, pois bloquearia todos os outros de ingressarem no fórum.
Isso não é algo que podemos fazer por razões técnicas. O mais óbvio é que já temos usuários que têm o mesmo endereço de e-mail de outras contas. Mas o maior é que simplesmente não podemos fazer isso. O projeto no qual estamos buscando incorporar o Discourse é o Pretendo Network, um projeto de emulação de servidor para a Nintendo Network. A Nintendo permitiu que seu sistema de contas reutilizasse endereços de e-mail e, para emular os servidores com precisão, também temos que fazer isso. Forçar e-mails exclusivos simplesmente não está em nossos planos.
Alguém da minha equipe sugeriu que executássemos nosso próprio servidor SMTP que lida com o mapeamento dos e-mails falsos do Discourse para os e-mails reais de nossos usuários, encaminhando os e-mails enviados do Discourse dessa forma. O que funcionaria, mas obviamente vem com um custo técnico maior para nós e ainda não resolve o problema de desabilitar o login por e-mail e o atrito mencionado que vem com nosso caso.
Parece que podemos ter que fazer um fork do Discourse ou usar outra solução de fórum para fazer o que precisamos.
Estou me baseando na memória, mas você pode usar o DiscourseConnect com endereços de e-mail falsos, mas exclusivos. Se os nomes de usuário forem garantidamente exclusivos do seu lado, a implementação pode ser bem simples. O endereço de e-mail pode ser definido como algo como username@invalid.com.
Os usuários farão login no seu sistema com o método que estiverem usando agora. Seu sistema, então, gerará a carga útil do SSO com o endereço de e-mail falso.
A desvantagem dessa abordagem é que você precisará desativar os e-mails no Discourse. Isso pode ser feito definindo a configuração disable emails como yes ou non-staff (se seus membros da equipe tiverem endereços de e-mail exclusivos).
Você também pode considerar o uso de endereços de e-mail com + para usuários com endereços de e-mail duplicados. Da última vez que verifiquei, o Discourse considerava os endereços de e-mail com + como exclusivos. Apenas certifique-se de codificar os endereços de e-mail em URL antes de usá-los na carga útil do DiscourseConnect. O risco aqui é que, se os usuários tiverem endereços de e-mail duplicados e usarem um servidor de e-mail que não suporta endereços de e-mail com +, eles não receberão e-mails do Discourse, mas isso permitiria que seus outros usuários recebessem e-mails do Discourse.
Sim, mas apenas para um caso específico. Se um usuário criou uma conta no Discourse antes que o site do Discourse implementasse o DiscourseConnect, o Discourse tentará associar usuários existentes ao endereço de e-mail que está na carga útil do DiscourseConnect. Se você estiver iniciando um novo site no Discourse, isso não será um problema.
Outro caso em que vi o problema de mapeamento de e-mail surgir é quando, devido a algum código defeituoso no site do provedor de autenticação, os registros de SSO no site do Discourse ficaram corrompidos. Nesse caso, o site conseguiu excluir todos os registros de SSO no lado do Discourse, e então fazer com que o Discourse associasse os usuários ao endereço de e-mail da carga útil do SSO na próxima vez que eles fizessem login. O Discourse, então, gerou novos registros de SSO para os usuários. Isso ainda funcionaria com endereços de e-mail falsos.
A lógica com a autenticação do DiscourseConnect é que o Discourse primeiro tenta encontrar o usuário com base no campo external_id da carga útil; se não encontrar um usuário, ele recorre à tentativa de encontrar o usuário com base no campo email da carga útil; se ainda não encontrar um usuário, ele gera um erro.
Verifique tudo isso antes de implementar em um site ativo, mas sei que a abordagem de e-mail falso tem sido usada em sites de produção para casos em que os endereços de e-mail reais dos usuários não podem ser compartilhados com o site do Discourse.
@simon Obrigado pelas informações! Isso está começando a parecer que estamos progredindo
Isso é bom, e eu mencionei anteriormente que esta é uma solução aceitável para o problema de “todos os e-mails devem ser únicos”. Estou perfeitamente bem em essencialmente desativar e-mails em nosso caso, e usar e-mails falsos foi uma solução que encontrei antes de fazer esta postagem.
Talvez eu não tenha sido claro originalmente, mas o ponto da postagem era ver se é possível forçar o prompt de login a aceitar apenas nomes de usuário, já que atualmente o login pode ser feito com um nome de usuário ou um e-mail. Se os logins por e-mail ainda forem exibidos como disponíveis no prompt de login no Discourse, nossos usuários podem tentar usar o endereço de e-mail de sua conta existente e encontrar um erro. Portanto, teríamos que lidar com pessoas tentando e falhando em usar seu endereço de e-mail atual ou de alguma forma informar o usuário sobre seu novo e-mail específico do fórum. Ambos podem causar confusão e atrito para os usuários, então, idealmente, poderíamos simplesmente restringir o prompt de login a aceitar apenas nomes de usuário.
Ter e-mails exclusivos para a equipe infelizmente também não é garantido, então eu não gostaria de depender disso. Essa configuração apenas desativa o envio de e-mails? Ou desativa o uso de e-mail como um todo, como o que estou procurando com o prompt de login?
Revisei a página do DiscourseConnect várias vezes e não vi essa opção lá. Existe talvez um lugar melhor para ver esse tipo de documentação? Não vi nenhum link para documentação completa naquela postagem, então presumi que todas as informações lá eram tudo o que havia.
Admito que ainda não configurei o DiscourseConnect para investigar as configurações. Eu esperava que a documentação fosse suficiente para entender o que pode e o que não pode ser feito, para que não tivéssemos que configurar uma instância de teste completa do fórum, a menos que soubéssemos que iríamos nos comprometer com isso. Mas parece que ainda há algumas informações não prontamente disponíveis, a menos que eu tenha perdido algo óbvio?
Isso também foi considerado anteriormente nesta thread, mas o problema ainda permanece que teríamos que lidar com logins de e-mail falhos ou informar o usuário sobre este novo endereço de e-mail do fórum. Remover esse atrito foi meu principal objetivo. Se isso não for possível de fazer aqui sem fazer um fork do Discourse, e a única solução for lidar com logins de e-mail falhos ou dar às pessoas um novo e-mail para lembrar, então podemos ter uma solução de fórum diferente.
Parece que eu entendi errado, isso não é muito claro com base na postagem em si. No entanto, meu ponto ao levantar isso foi ilustrar a dependência de e-mails serem únicos, o que ainda seria um problema.
Isso DEFINITIVAMENTE não estava claro apenas com base na postagem, a menos que eu tenha perdido algo. Obrigado por essa clarificação! Isso soa mais alinhado com o que eu esperava.
Até onde eu sei, não é possível forçar o prompt de login do Discourse a exibir apenas o campo de nome de usuário. Você também ficaria preso tentando descobrir como fazer com que os usuários se registrem em primeiro lugar. É por isso que estou sugerindo o DiscourseConnect.
Quando o DiscourseConnect é ativado, ele se torna o único sistema de autenticação para o seu site Discourse. Quando os usuários clicam no botão de login no Discourse, eles são redirecionados automaticamente para a URL que você adicionou à configuração do site discourse_connect_url. Seu sistema de autenticação assume o controle a partir daí. Isso significa que, se você tiver um site ao qual os usuários podem atualmente fazer login com nome de usuário e senha, eles continuarão a fazer login dessa maneira.
Se adicionar código ao seu site atual não for possível, você também pode criar um pequeno site ao qual os usuários possam fazer login com nomes de usuário e senhas, e então adicionar o código do DiscourseConnect a esse site. Seria menos trabalho do que fazer um fork do Discourse.
Obrigado! Parece que eu tinha um entendimento fundamental equivocado do DiscourseConnect. Eu tinha a impressão de que a página de login permanecia no Discourse, e ele simplesmente se comunicava com o servidor externo. Eu não sabia que o usuário era direcionado para uma página de login diferente, de nossa escolha.
Meu equívoco sobre o DiscourseConnect parece ter sido o cerne deste problema e de toda a confusão.
Se você não se importa com o Discourse enviando e-mails para notificações, você pode fazer com que seu SSO forneça ao Discourse o endereço de e-mail game-username@bogus.invalid.
Pode ser possível então que os usuários adicionem um segundo endereço de e-mail real e, em seguida, troquem o falso pelo secundário.
Minhas desculpas, não vi sua resposta ontem à noite
Eu não tinha. Como eu disse antes, não queríamos prosseguir com uma implantação de teste até sabermos que o Discourse era utilizável. Então, na verdade, não tentei nada, até agora apenas lemos sobre seus recursos e perguntamos aqui quando as coisas não estão claras. Isso é realmente fantástico de ouvir, eu não sabia que poderíamos controlar as coisas nesse nível
Honestamente, parece bastante difícil encontrar documentação real sobre qualquer coisa fora da API. Pelo menos vindo da perspectiva de um usuário iniciante.
Não há nada óbvio na página inicial do Discourse que leve a qualquer documentação, e todos os links na página do DiscourseConnect levam a páginas não relacionadas ou de volta à própria postagem. Tentar pesquisar por “documentação do Discourse” em mecanismos de busca apenas leva a páginas como Documentation - Discourse Meta, que é apenas a categoria do fórum para isso, não uma página de documentação real, e https://docs.discourse.org/, mas esta é a documentação da API e não tem nada sobre recursos como o DiscourseConnect, aparentemente.
Tentar encontrar organicamente essas informações provou ser difícil.
Existe algum lugar óbvio que eu simplesmente perdi onde tudo isso é abordado? Parece que o mais próximo que consigo encontrar é a categoria do fórum, pois existem muitos guias/tutoriais escritos por funcionários e outros sobre vários tópicos. Mas reutilizar o fórum para documentar a si mesmo não me pareceu certo? Não há uma fonte de documentação dedicada para recursos/ferramentas do Discourse como há para a API do Discourse?
Correto, isso funcionaria. Como afirmado algumas vezes, usar um e-mail falso do provedor oauth foi algo que concluímos antes mesmo de fazer esta postagem.
Mas isso, por si só, não resolve o problema de “se um usuário vir no prompt de login que os e-mails são aceitos, ele tentará usá-los e falhará devido a ter um e-mail falso”.
No entanto, acabei tendo um mal-entendido sobre como o DiscourseConnect funciona. Eu tinha a impressão de que o formulário de login ainda estava no Discourse, e que o Discourse simplesmente entrava em contato com o provedor oauth. O @simon me corrigiu agora, eu não sabia que ele fisicamente movia o usuário para fora do site para o nosso próprio formulário de login. Isso, por si só, resolve basicamente todos os problemas que eu tinha. Obrigado, no entanto!
Mesmo que você só queira dar uma olhada e não pretenda continuar usando nossa hospedagem, sinta-se à vontade para iniciar um site de teste! Não nos importamos!
Obrigado por este feedback - estamos fazendo um esforço consciente para melhorar isso.
Você se importaria se entrássemos em contato para discutir mais?
Nenhuma das pessoas com quem trabalhei ficou insatisfeita com a hospedagem do discourse.org. Se você precisar auto-hospedar por algum motivo, pode fazer login em https://dashboard.literatecomputing.com/ e entrar no grupo “teste gratuito” e usar o Dashboard gratuitamente (se você não conseguir descobrir como entrar no grupo de teste gratuito, provavelmente precisará de mais suporte do que estou disposto a oferecer). Se você estiver disposto a usar o Digital Ocean e o mailgun, você só precisa inserir chaves de API e um nome de host.
Eu, envergonhadamente, nem pensei nessa opção! Esse é um bom ponto e provavelmente faremos isso para fins de teste.
Eu já havia olhado suas opções de hospedagem hoje mais cedo, pois seria mais fácil do que auto-hospedar, mas infelizmente parece estar fora do nosso orçamento. Temos mais de 200.000 usuários, então o plano “Básico” não é uma opção. Temos mais de 5 funcionários, então o plano “Padrão” não é uma opção. E, como um projeto FOSS, operamos com doações e mal conseguimos o suficiente para manter as luzes acesas e pagar um único desenvolvedor em tempo integral, então o plano “Empresarial” está muito fora de alcance.
Usar o teste para fins de teste é uma ideia fantástica, no entanto, obrigado! Já auto-hospedamos a maioria dos nossos serviços, até mesmo nossa instância Mastodon, então auto-hospedar o Discourse não é um grande obstáculo.
Claro! Sempre feliz em ajudar se puder, mesmo que apenas dando algum feedback. Espero que não tenha parecido muito negativo, pois essa não foi a intenção, para ser claro.
Se você estiver interessado, oferecemos hospedagem gratuita para alguns projetos FOSS… seus números de funcionários são maiores do que nossos limites, mas as pessoas que tomam a decisão podem conseguir relevar isso.
(observe que nossa definição de “funcionários” aqui é “Administradores” + “Moderadores em todo o site”, não “funcionários da respectiva empresa” - eu ficaria curioso sobre qual era a definição de funcionários em sua mente antes disso)
Obrigado! Eu tinha perdido isso em sua página de preços. Acabei de voltar para verificar novamente e está enterrado bem no final da página Vou analisar isso e conversar com o meu pessoal!
Nossa definição de “equipe” neste caso abrange 2 papéis amplos:
Pessoas em nossa equipe principal de desenvolvimento (como um projeto de código aberto, isso pode flutuar, pois as pessoas podem ir e vir, mas tivemos ~5-10 desenvolvedores ativos ao longo dos anos em qualquer momento)
Nossa equipe de moderação (não desenvolvedores e membros da comunidade que moderam nossos serviços, como partidas online e nossa implementação do Miiverse, bem como nosso servidor Discord). Isso também varia
NÓS PODERÍAMOS limitar isso a apenas 5 de nossos desenvolvedores, o que se encaixaria nesses limites, mas exigiria que decidíssemos quem teria ou não direitos plenos no fórum. Isso também limitaria o número de pessoas capazes de moderar os fóruns (introduzimos uma equipe de moderação fora da equipe de desenvolvimento para tirar essa carga apenas de nós em primeiro lugar)
Definitivamente vou levantar isso com as pessoas do meu lado e ver como as coisas vão!
Vou analisar isso e conversar com o meu pessoal!