Olá!
Estamos enviando um convite do Discourse para nossos usuários assim que eles criam uma conta no nosso aplicativo. Já temos o nome deles e os campos personalizados que precisamos para nossa comunidade, mas o usuário precisa digitar essas informações novamente no Discourse.
Existe alguma maneira de preencher esses campos como parte do perfil deles?
Obrigado!
Acho que o ideal seria que seu aplicativo atuasse como o servidor SSO. Se não for isso que deseja, então seu aplicativo pode criar o usuário por meio da API e incluir essas configurações. Você pode descobrir como fazer isso em Como fazer engenharia reversa da API do Discourse.
Não queremos criar usuários via API, pois queremos que o usuário crie uma senha e escolha seu nome de usuário. Estava considerando criar um usuário em estágio com todos os dados, mas parece que isso não é possível via API.
A outra opção que consigo pensar é estender os convites para permitir campos personalizados e informações de perfil.
Talvez um plugin que busque os campos do seu aplicativo por meio de uma chamada de webhook/API? Você poderia configurar o plugin para fazer algo como get yoursite/user/<email_address> e preencher os campos do usuário quando o registro do usuário for atualizado. Algo assim. O SSO ainda parece ser a melhor solução.
Sim, por favor, confira Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Este é exatamente o caso de uso para o Single Sign On.
Com o SSO, no entanto, você não precisaria convidá-los. Eles apenas visitariam sua instância do Discourse e seriam automaticamente logados se já estiverem logados no seu aplicativo. Se eles ainda não estiverem logados no seu aplicativo, o Discourse os redirecionará para o seu aplicativo para fazer o login e, em seguida, eles serão redirecionados automaticamente de volta ao Discourse.
O problema é que estamos usando o Discourse como nosso provedor de SSO e isso tem funcionado bem para nós, mas sim, concordo que seria mais fácil se o Discourse consumisse um provedor de SSO.
@blake Ainda estou pensando em como podemos fazer isso, já que estamos usando o Discourse como nosso provedor de SSO. Não quero migrar para outra solução no momento, pois isso exigiria muito mais trabalho. Você tem outras ideias? Não há problema se precisarmos escrever código personalizado, mas queremos fazer o menor número possível de alterações na configuração atual.
Obrigado!
Estou apenas confuso com sua configuração e essas duas frases, porque, nesse caso, você não tem Single-Sign-On (SSO), mas sim Double-Sign-On?
Se o Discourse fosse seu SSO, novos usuários do seu aplicativo deveriam ser redirecionados primeiro para o Discourse para criar uma conta e, em seguida, redirecionados de volta para o seu aplicativo, após serem autenticados. Assim, todas as informações estariam em um único lugar.
Com base no meu entendimento atual, eu transformaria seu aplicativo em um provedor de SSO e faria com que o Discourse o consumisse. Ou redirecionaria os usuários do seu aplicativo para se cadastrarem primeiro no Discourse e, em seguida, os redirecionaria de volta para o seu aplicativo, porque, aparentemente, não é assim que está configurado atualmente?
Caso contrário, se você quiser ter uma configuração de dual-sign-on, assim que eles se cadastrarem no seu aplicativo, crie-os automaticamente como usuários no Discourse via API, com uma senha aleatória que você nunca fornecerá ao usuário, e preencha automaticamente as informações do perfil que eles informaram no seu aplicativo. Em seguida, envie-os para a página de redefinição de senha no Discourse para sua nova conta, em vez de enviar um convite.
Fazemos o registro através do nosso aplicativo, mas nosso aplicativo não possui gerenciamento de sessão. Apenas cobramos o usuário e armazenamos suas informações em nosso banco de dados.
Precisaremos exigir que o usuário crie uma conta primeiro, e é esse passo que estamos removendo, pois queremos tornar o processo o mais fácil possível.
Esse é o esforço que não queremos assumir, pois adicionar gerenciamento de sessão, recuperação de senha, autenticação 2FA e todos os recursos que o Discourse oferece demandaria muito trabalho.
Isso não é o que queremos.
Foi isso que fiz inicialmente, mas temos que definir um nome de usuário aleatório, e isso não é o que queremos. Embora funcione, queremos que o usuário ainda possa personalizar sua conta antes de começar a usar a comunidade.
Mas sim, acho que a resposta ainda é usar um provedor de SSO externo. Vou seguir por esse caminho e parar de pensar em como aproveitar o Discourse e fazê-lo funcionar da maneira que queremos.
Obrigado pela ajuda @blake!
Ou você pode dispensar seu aplicativo e deixar o Discourse Subscriptions cuidar do dinheiro?