É a única coisa que essa configuração faz?
Acho que o nome e a descrição no WP são bastante vagos, então eu estava me perguntando o que mais ela poderia fazer?
Em relação a isso,
e se um usuário já existir no WordPress e no Discourse. Como faço para mesclar / conectar os perfis deles?
Tecnicamente, o que ele faz é fazer uma chamada para a rota sync_sso do Discourse e passou seus dados (WordPress user_id, username, name, email…) para o Discourse imediatamente após o login no WordPress. Detalhes sobre a rota sync_sso estão aqui: Sync DiscourseConnect user data with the sync_sso route.
O único efeito colateral disso que eu estou ciente para usuários do WordPress que nunca visitaram o site do Discourse é que eles começarão a receber e-mails de resumo do Discourse.
É por isso que você quer incentivar seus usuários do Discourse a se registrarem no WordPress com o mesmo endereço de e-mail que estão usando no Discourse. Desde que os endereços de e-mail correspondam, eles serão logados na conta correta do Discourse. Isso pressupondo que você cuide da questão da verificação de e-mail que discutimos em posts anteriores.
É provável que você acabe com alguns usuários se inscrevendo no WordPress com endereços de e-mail diferentes dos que usaram no Discourse. Para esse caso, uma nova conta do Discourse será criada para eles, usando o endereço de e-mail do WordPress. Você precisará mesclar manualmente a conta antiga do Discourse na nova conta do Discourse: Merging user accounts.
3 curtidas
O que acontece se tivermos que atualizar manualmente o e-mail de um usuário no WordPress. O e-mail do Discourse também é atualizado se essa configuração estiver habilitada?
1 curtida
Atualizar um usuário a partir da página de perfil do WordPress não aciona a chamada para sync_sso. Provavelmente deveria fazer isso. Por enquanto, você precisará pedir que eles saiam do WordPress e, em seguida, façam login novamente no WordPress. Não acredito que seja possível para um administrador desconectar um usuário do WordPress a partir da página de perfil dele.
Se você quiser manter os e-mails e/ou nomes de usuário sincronizados entre o WordPress e o Discourse, ative estas configurações do Discourse:
auth overrides emailauth overrides username
1 curtida
Obrigado, Simon. Acho que este é o processo que seguirei após considerar tudo:
- Exportar usuários do Discourse
- Ativar o Discourse Connect
- Importar e criar esses usuários no WordPress e marcar seus e-mails como verificados no WP
- Quando esses usuários fizerem login (via página de login personalizada), eles terão que redefinir suas senhas
- De alguma forma forçar apenas este segmento de usuários a alterar suas senhas depois que eles inserirem seus e-mails (e o sistema perceber que eles fazem parte deste segmento)
- OU apenas mostrar uma mensagem na página de login: “se você estiver fazendo login após [data], você deve REDEFINIR sua senha”
- O acesso deve funcionar!
Quanto às novas inscrições que chegarem, precisarei descobrir uma maneira de verificar os e-mails. Provavelmente enviarei suas senhas por e-mail.
Também notei que, mesmo que a configuração “Endereço de e-mail verificado” não esteja selecionada no perfil do WordPress, o usuário ainda pode fazer SSO no Discourse. Eles precisam confirmar seu e-mail de qualquer maneira na primeira vez que entram no Discourse. O que é bom.
Essas configurações têm algum efeito colateral?
1 curtida
Sim, é assim que se pretende que funcione. Isso não é uma grande barreira para a maioria dos usuários. O problema que você precisa estar ciente é que, se o endereço de e-mail não estiver marcado como verificado no WordPress, o Discourse não associará usuários do WordPress a usuários do Discourse com base em seus endereços de e-mail na primeira vez que eles fizerem login no Discourse via DiscourseConnect. Contanto que você descubra como marcar os endereços de e-mail de seus usuários importados como verificados, isso não causará um problema. Se você não os marcar como verificados, será um incômodo para resolver as coisas.
Se habilitadas, elas impedem que os usuários alterem seus nomes de usuário ou endereços de e-mail no Discourse.
1 curtida
Sim, eu estava testando muito e percebi isso. Vou apenas escrever um script personalizado que marcará todos os usuários que eu importar como verificados.
Obrigado por esclarecer!
1 curtida
É aceitável manter o modo verbose /logs ativado para sempre?
Isso impactará negativamente o desempenho?
Já vi casos em que eles foram mantidos ativados para sempre. Não acredito que isso tenha um impacto significativo no desempenho. Apenas polui seus logs se você estiver tentando depurar um problema que não está relacionado ao DiscourseConnect.
2 curtidas
Tudo tem funcionado muito bem até agora!
Uma pequena coisa que estou notando é que qualquer caminho que eu insira neste campo:
torna-se a página de login padrão do WordPress.
Por exemplo, se eu tentar agora ir para /wp-admin, que é o que eu usaria anteriormente para fazer login como administrador, ele me redireciona para /login/forum
Idealmente, ele só redirecionaria para isso quando alguém clicasse no botão de login do fórum Discourse.
Gostaria de saber se este é o comportamento normal e se é algo ruim que funcione assim.
Esse é o comportamento esperado. A opção “Caminho para sua página de login” é usada para substituir o caminho de login padrão do WordPress. Isso é feito conectando-se ao filtro login_url do WordPress.
Ele não remove a rota de login padrão em /wp-login.php, então você ainda pode acessar diretamente essa URL digitando-a na barra de endereços do seu navegador. Em vez de ir para /wp-admin, vá para /wp-login.php para usar a página de login padrão.
Posso pensar em uma maneira de o plugin ser atualizado para redirecionar apenas para o caminho “Caminho para sua página de login” para fazer login no Discourse, mas essa alteração exigiria um pouco de trabalho.
4 curtidas
Sem problemas. Apenas uma pequena coisa. Obrigado pelas informações!
1 curtida
Olá @simon, estou vendo os seguintes erros no meu log e gostaria de saber o que significam e como resolvê-los. Notei estes erros depois que um usuário disse que estava recebendo um erro ao tentar fazer login.
-
(google_oauth2) Falha na autenticação! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detectado
-
Falha na autenticação! request_error: OAuth::Unauthorized, 401 Unauthorized
-
(facebook) Falha na autenticação! no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError, deve passar um
code(via URL ou por um cookie assinadofbsr_XXX)
Vale a pena notar que esses erros não são comuns. A maioria dos logs parece estar funcionando com sucesso:
Acabei de receber esta captura de tela do usuário:
Ele disse: “Não há e-mail. Assim que você clica no link de inscrição, você é apresentado à seguinte página…”
quando clico no link de login/inscrição (no modo anônimo), funciona para mim.
Aqui está o URL do nosso fórum como referência: forum.projectvanlife.com
Estou assumindo que as entradas que começam com “Verbose SSO log” mostram logins bem-sucedidos.
Para os erros “google_oauth2”, “OAuth::Unauthorized” e “facebook”, não tenho certeza do que está acontecendo. Seu site Discourse estava configurado anteriormente para permitir que os usuários fizessem login via Google e Facebook? Se sim, eles não poderão mais fazer login no site com esses métodos agora que o DiscourseConnect está habilitado. Talvez tente desabilitar os logins do Google e do Facebook na sua página de configurações do Discourse.
Para usuários que relatam erros ao fazer login, tente encontrar uma mensagem de erro detalhada no log do SSO que esteja associada à tentativa de login do usuário. Em seguida, veja se o erro corresponde a algum dos problemas descritos neste tópico: Debug and fixing common DiscourseConnect issues.
A URL mostrada na barra de endereço do navegador é https://projectvanlife.com/login/forum/javascript%3Avoid(0.
Estou assumindo que parte do javascript está sendo truncado e que na verdade ele deveria ser decodificado para javascript:void(0). Não tenho certeza de onde isso poderia estar vindo. Possivelmente de uma das extensões do navegador do usuário. Tente pedir a eles para desabilitar suas extensões do navegador, ou para tentar fazer login de uma janela anônima.
Editar: @Sami_Syed o código javascript:void(0) está sendo anexado ao caminho quando o link “Inscrever-se” da página de login é clicado. O href desse link é: \"javascript%3Avoid(0)\"
Eu acho que o que está sendo usado é para ter o formulário de inscrição no mesmo caminho que o formulário de login. Algo está dando errado com isso, no entanto. Você sabe se isso estava funcionando corretamente antes do DiscourseConnect ser habilitado?
Se o plugin usado para os formulários de login/inscrição tiver uma opção para que o formulário de inscrição apareça em uma página separada, habilitar isso deve funcionar como uma correção rápida para o problema.
Estarei offline na maior parte do dia de hoje, mas posso tentar ajudar com isso mais tarde se você estiver preso.
Editar: Fiquei intrigado com isso, então dei outra olhada. A aba “Registrar” no formulário de login funciona sem problemas. O link “Inscrever-se” tem o problema que descrevi acima:
Portanto, a correção rápida para o problema é simplesmente remover o link de inscrição.
2 curtidas
Isso está correto.
Sim, isso estava ativado. A questão é, como eles conseguem acionar um login via FB ou Google agora? Nossa página de login atual não tem esse recurso.
Ou esse erro está aparecendo para aqueles que se inscreveram originalmente usando G ou FB e agora estão tentando fazer login, mas não funciona?
E se for esse o caso, como posso resolver isso?
Como vejo, é porque eu não defini um link correto lá. Oops. Bom ponto e obrigado!
Não sei o que poderia estar acionando isso. Talvez a URL para o provedor de autenticação tenha sido armazenada em cache pelo navegador do usuário. Isso é apenas um palpite.
1 curtida
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.