Estou trabalhando em um site WordPress que tem um Fórum Discourse conectado a ele com aproximadamente 200 mil usuários.
Usando os plugins OAuth Single Sign On - SSO (OAuth client) e WP-Discourse, conectamos as postagens do WP ao Discourse e fazemos os usuários fazerem login no WP com sua instância de usuário do WP, que então os loga no Discourse também.
Agora, um problema apareceu, sempre que definimos as configurações do Discourse para não exigir login.
Estes são os nossos passos:
O usuário faz login no WordPress
O usuário clica em um link que leva ao Discourse (um tópico, qualquer link que leve ao Discourse)
==> O usuário agora vê o Discourse como se não estivesse logado! Mas eles estão logados, no momento em que fizeram login no WordPress!
Agora o usuário clica no login do Discourse ou em qualquer link de tópico
A página é atualizada e o usuário está autenticado!
Fomos informados de que isso é esperado e que precisamos fazer o seguinte:
quando o usuário estiver logado, todos os links que levam ao Discourse do WordPress devem ser os seguintes: https://nossa-instancia-discourse.com/session/sso?return_path={URL ORIGINAL DO DISCOURSE PARA O QUAL ESTAMOS APONTANDO, como um URL de tópico, ou algo assim}
quando um usuário estiver deslogado, podemos vincular diretamente ao {URL ORIGINAL DO DISCOURSE PARA O QUAL ESTAMOS APONTANDO, como um URL de tópico, ou algo assim}, assim https://nossa-instancia-discourse.com/t/slug-do-topico
Suspeito fortemente que essa seja a abordagem errada para resolver esse problema, porque:
E se um usuário, enquanto logado no Discourse, copiar um URL de tópico e compartilhá-lo com alguém que também está logado no WP/DIscourse? Eles terão o mesmo erro mostrado acima no nº 2, já que nenhum sufixo de URL seria anexado.
Por que um usuário logado precisaria ser redirecionado para session/sso?return_path=? Qual é o raciocínio técnico e a lógica por trás disso?
Por que é resolvido assim que o usuário recarrega a página (carrega um URL de tópico, clica em login, etc.)?
Por que isso não é mais amplamente documentado, se essa fosse a abordagem esperada?
Por que isso não seria mencionado na API, onde podemos extrair qualquer URL de tópico do Discourse, e em NENHUM lugar está escrito que usuários logados não conseguirão acessar o conteúdo imediatamente e primeiro precisarão fazer recargas estranhas, ou que precisamos anexar parâmetros de URL estranhos que, de fato, não convertem nada?
Eu realmente apreciaria uma opinião autorizada sobre isso, porque não estou nada convencido de que este seja o comportamento esperado!
Se for, gostaria de perguntar:
por que isso é realmente necessário e
o que está planejado a ser feito a respeito (porque isso certamente não é o ideal, veja o ponto 1 das minhas razões pelas quais isso não deveria ser esperado)
Se você quiser que seus usuários sejam redirecionados automaticamente para o login quando acessarem qualquer caminho em seu fórum, você precisará habilitar a configuração login required. Este é, de fato, o comportamento esperado.
Embora ainda pareça estranho, adicionei um redirecionamento para session/sso?return_path= no login do usuário no wp
O caminho de retorno que defini é o referenciador do wp (se houver) ou a página inicial do wp
Isso funciona muito bem e garante que o usuário esteja logado em ambas as instâncias
Tive que habilitar a configuração no discourse para permitir “qualquer caminho de retorno”, pois, por padrão, o discourse não permite caminhos de retorno “externos”
Você vê algum problema em habilitar esta configuração?
Obrigado novamente pela gentil resposta e pela confirmação “oficial”, além do link da documentação!
Normalmente, aconselho os clientes a não fazerem um redirecionamento automático como este. Entendo por que você sente que isso é um problema, é um sentimento nada incomum, no entanto, a abordagem padrão funciona muito bem para muitos sites, grandes ou maiores que o seu, e o redirecionamento automático pode não funcionar em alguns cenários, levando a uma má experiência do usuário.
O login único que faz login automaticamente em todos os lugares que você espera é como serviços interconectados como a Meta (por exemplo, faça login no Facebook e você estará logado no Instagram) às vezes funcionam porque são plataformas centralmente controladas (embora até mesmo serviços centralizados às vezes funcionem da mesma forma que o DiscourseConnect).
Em contraste, você está lidando com frameworks de software de código aberto independentes aqui (ou seja, Wordpress e Discourse). Eles podem ser configurados para funcionar efetivamente da maneira que você espera, mas requerem trabalho personalizado específico que leva em conta seu caso de uso específico. Nunca será como um sistema de autenticação como o DiscourseConnect, que atende a milhares de casos de uso diferentes.
Não, com a ressalva de que questionaria a premissa de precisar dela. Mas sem mais informações, não vejo problema em usá-la.
Isso poderia ser um risco de redirecionamento não validado, como descrito aqui?
Posso ver como “permitir qualquer valor de retorno” realmente permite redirecionar para qualquer lugar.
Mas não tenho certeza se isso realmente seria um risco, já que nenhum dado sensível é compartilhado para ou a partir dessa URL de redirecionamento.
Desculpe, isso seria entrar em dar conselhos sobre uma parte sensível da sua configuração sem vê-la pessoalmente ou ter um relacionamento definido com você.
Particularmente, considerando o tamanho do seu fórum e os regulamentos relevantes que se aplicam a ele, eu recomendaria que você obtivesse aconselhamento específico e informado sobre essa questão.
Um fórum Discourse ativa a configuração no Discourse para permitir “qualquer caminho de retorno”
Isso significa que agora você pode visitar seu-discourse.tld/session/sso?return_path=QUALQUERCOISA
QUALQUERCOISA pode ser um URL externo
Assim, isso abre uma vulnerabilidade de segurança, pois pelo menos uma tentativa de phishing pode ser encenada:
um site malicioso cria um botão dizendo “vá para a comunidade incrível!”
o link do botão é seu-discourse.tld/session/sso?return_path=DE VOLTA PARA O SITE MALICIOSO
o usuário clica no botão, faz login na comunidade, o que o leva de volta ao SITE MALICIOSO
lá, o ator malicioso implementou uma página que se parece exatamente com a comunidade e diz “algo deu errado enquanto você fazia login, por favor, tente novamente”
o usuário envia um formulário de login com aparência agradável que corresponde à aparência da comunidade.
O ator malicioso agora capturou os dados de login?
Assim, provavelmente a configuração “qualquer caminho de retorno” não deve ser usada nunca para um site que tem usuários fazendo login, a menos que cada usuário saiba exatamente o que procurar.
Você também veria esse risco?
Por que os desenvolvedores do Discourse, ao criar plugins/código que podem interagir com essa configuração, não poderiam dar um aceno para “sim, sem problemas” ou “nem pensar”?
Não são muitas as coisas que podem mudar nesse parâmetro de URL. Ele está lá ou não, ele permite externos ou não.
Talvez eu esteja entrando em uma área que não deveria, como em “não discuta problemas de segurança aqui”? Eu entenderia isso, é claro, muitas plataformas não permitem falar abertamente sobre potenciais problemas de segurança que não são claramente definidos ao ativá-los
Acho que você já respondeu à sua própria pergunta.
Porque a valência das configurações depende de como elas são usadas, de fato é por isso que elas são configurações e não apenas “recursos”. Se houvesse uma resposta simples para sua pergunta, não haveria uma configuração em primeiro lugar.
Agradeço que esta resposta um tanto jurídica seja frustrante. Mas você precisa de conselhos específicos para o seu caso de uso, o que não estou em posição de lhe dar aqui.
