Eu adoraria ver uma opção para adicionar um token ao link “visitar tópico” quando os usuários receberem um e-mail do Discourse, permitindo que eles sejam automaticamente logados ao clicar no link.
Muitos clientes de e-mail baseados em aplicativos — como o Gmail — usam uma visualização web para carregar os links que você clica, caso não haja cookies salvos, mesmo que você tenha feito login anteriormente. O resultado é que os usuários ficam impedidos de responder se não tiverem suas credenciais de login à mão e, muitas vezes, desistem da intenção de responder.
Acho que isso seria facilmente resolvido se houvesse uma opção para adicionar um token que fizesse o login automático do usuário, permitindo que eles respondessem imediatamente ao clicar no link. Uma opção adicional para definir a duração de validade do token também seria muito útil.
Certamente é uma solução criativa para um problema que eu resolveria recomendando não usar a web view do cliente de e-mail, ou responder diretamente por e-mail.
Eu não uso sistemas de login de terceiros, mas acho que esse conceito entra um pouco em conflito com o funcionamento deles, certo? Se você clicar em links para outros sites que fazem login com uma conta de rede social, como isso é tratado na web view do cliente de e-mail? Os tokens de login funcionam nesse cenário?
Embora eu entenda o que você está dizendo, acho que você já perdeu o usuário médio, que provavelmente nem entende a diferença entre uma web view e abrir no Safari móvel.
Muitos sites fazem algo semelhante, com a ideia parecida com um ‘link mágico’ ao fazer login em serviços como o Slack. Em vez de inserir seu nome de usuário e senha, você pode solicitar um link mágico enviado por e-mail. Ao clicar no link mágico, você fica logado. O link mágico é uma URL tokenizada.
Se você pode redefinir sua senha com um link enviado ao seu e-mail, qual é a diferença?
O que eu quis dizer foi: links mágicos funcionam quando um usuário se cadastrou com uma conta de rede social? Eu não sei. Sua funcionalidade pode estar entrando em conflito com muitos sistemas de login, então eu estava antecipando a P&D.
Desculpe não ter abordado isso… um desenvolvedor principal do Discourse saberia melhor do que eu, mas em sistemas semelhantes nos quais trabalhei, não deveria ser um problema. Seu SSO, seja social ou outro, é basicamente apenas uma troca de tokens entre o provedor de serviço SSO e o Discourse. Então, na verdade, seria semelhante, exceto que, neste caso, seu SSO seria seu e-mail. Simplificando um pouco, mas de modo geral, imagino que funcione bem.
Isso é muito específico do iOS, certo? O equivalente no Android (Chrome Custom Tabs) compartilha cookies por padrão, então isso não é um problema no Android.
Não tenho certeza absoluta e ainda não tive a oportunidade de testar em um dispositivo Android. Mas acho que vai além desse caso de uso. Mesmo que você esteja no desktop e simplesmente não tenha participado da comunidade há algum tempo, isso incentivaria o engajamento, pois faria o login automático quando você fosse responder.
Geralmente, desativei a resposta por e-mail na maioria das instâncias do Discourse que gerenciamos, porque o resultado da análise do e-mail pode ser inconsistente e a interface móvel da web do Disqus é excelente. Então, quando funciona (você já está logado), clicar em “visitar tópico” (eu até poderia adicionar um botão “responder agora” que abre a caixa de diálogo de resposta) é quase tão fluido quanto clicar em responder no seu cliente de e-mail.
