Olá @balazsorban44, obrigado pelo lembrete. Fiz uma primeira revisão do PR. Se o autor não tiver tempo para trabalhar nessas coisas, é provável que possamos assumir. Concordo que ter suporte a PKCE seria bom.
No entanto, vale notar: não acho que o Discourse seja vulnerável aos ataques de “interceptação de código de autorização” contra os quais o PKCE protege. A autenticação do Discourse sempre acontece no navegador via https e não usa esquemas de URL personalizados de nível de sistema operacional que podem ser interceptados por outros aplicativos.
Mas, claro, não há problema em adicionar a camada extra de segurança
Olá Chris,
Como você integrou o Authentik com este plugin? Qualquer insight seria útil. Estamos lutando há algumas semanas para fazê-lo funcionar corretamente.
Hmm, não consigo me lembrar de algo especial. Qual é exatamente o seu problema? Você quer compartilhar algumas capturas de tela da sua configuração (talvez por mensagem privada)?
obrigado por responder, Chris. Claro. Falarei com você mais tarde esta semana, quando minha equipe de desenvolvimento que estava trabalhando no Authentik estiver por perto. Os principais problemas são com o fluxo e o outpost.
Tenho um problema interessante, antes de implantar publicamente, quero testar se tudo funciona, então meu provedor OIDC está hospedado localmente (sub-rede privada) e não é acessível pela internet.
Infelizmente, isso falha porque o Discourse não permite a conexão com IPs privados. oidc.example.org resolve para um IP privado.
Log OIDC: Buscando documento de descoberta em https://oidc.example.org/application/o/discourse/.well-known/openid-configuration
Log OIDC: Buscar documento de descoberta gerou erro Faraday::ConnectionFailed FinalDestination: todos os IPs resolvidos foram desautorizados
Log OIDC: Documento de descoberta é
---
(oidc) Fase de solicitação iniciada.
(oidc) Falha na autenticação! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Documento de descoberta está ausente
Acho que como openid_connect_discovery_document só pode ser alterado pelo Admin, ele deve ser confiável e permitir até mesmo IPs privados.
Existe uma configuração de site chamada ‘allowed_internal_hosts’. Se você adicionar o nome de host interno a essa lista, as solicitações para ele serão permitidas pelo SSRF Detector.
Em serviços de hospedagem compartilhada (como a hospedagem oficial do discourse.org), os administradores não são confiáveis para fazer solicitações dentro do ambiente de hospedagem, é por isso que essa proteção existe por padrão.
Desculpe, mas não tenho certeza se posso seguir a instrução para instalar o plugin. Estou executando o Discourse no meu ambiente Docker local, e realmente não consigo encontrar um app.yml para adicionar a configuração.
Pode ser uma pergunta idiota, mas há um guia para instalar em um ambiente de desenvolvimento local?
Para um ambiente de desenvolvimento Docker, tente verificar em /var/discourse/containers/app.yml?
No entanto, para instalações de desenvolvimento não Docker, veja aqui:
Durante uma instalação manual de pacote, recebo isto:
Mensagem pós-instalação de oauth2:
Você instalou a versão 1.4.11 do oauth2, que está em fim de vida.
Não se espera mais suporte para a série 1.4.x.
e recomendações para atualizar para a versão 2 do oauth2. Seria muito mais confortável sem essas mensagens, há planos para atualização?
Também recebo:
Parabéns! Você instalou a versão 1.1.0 do oauth.
O suporte não comercial para a série 1.x terminará até abril de 2025. Por favor, planeje uma atualização para a próxima versão antes dessa data.
A única mudança que causará quebra será o suporte removido para Ruby 2.7 e outras versões que também terão chegado ao fim de sua vida útil até então.
Olá,
a opção Permitir novos registros é estritamente necessária para o funcionamento do plugin. Isso permite criar automaticamente a conta na primeira conexão ao Discourse e exibe um botão “register”. Mas seria possível permitir a desativação: ou seja, não deixar a possibilidade para o usuário que se conecta via OpenID Connect de modificar seus parâmetros e criar diretamente sua conta. Isso permitiria remover da exibição os botões “register” que não têm razão de existir neste contexto.
E aí, você conseguiu configurar isso? Não sei por que estou travado nisso, de centenas de aplicativos que gerenciei com openid ou autenticação, este está me dando mais trabalho.