Isso é ótimo mesmo, TLS também é um requisito para o Exchange Online. Mas ainda assim, a autenticação é feita por basic-auth (se eu entendi bem o código a seguir, não há como escolher entre qualquer outro mecanismo de autenticação como OAuth2) discourse/poll_mailbox.rb at tests-passed · discourse/discourse (github.com)
Ela apenas espera um usuário e uma senha, em vez de um usuário e um token, além de precisar usar o formato AUTH XOAUTH2 para codificar e transmitir o token.
Desculpe se não fui claro na minha pergunta, mas estou perguntando mais sobre ter uma abordagem semelhante aos exemplos a seguir:
Essas abordagens permitirão que o Discourse se conecte ao POP3 (e, portanto, ao IMAP) com autenticação OAuth2, cumprindo assim os requisitos para a MS e provavelmente para o Gmail no futuro próximo, se não agora ( OAuth 2.0 Mechanism | Gmail IMAP | Google Developers).
Acho que este é um pedido de recurso muito bom e apoio muito a adição de suporte OAuth2 ao POP3.
Não posso me comprometer com o prazo de quando poderemos implementá-lo, mas se um PR (Pull Request) surgisse, certamente priorizaríamos a revisão e a mesclagem dele.
Pelo que entendi, o Google/Gmail desabilitou a autenticação POP3 que não seja OAuth em 30/05. Portanto, não consigo mais buscar e-mails via POP3. Seria ótimo se o Discourse suportasse OAuth2.
Não encontrei nenhum outro tópico além deste. Sou o único usando o Gmail com o Discourse?
Bump porque o Google também está prestes a encerrar as contas do Workspace.
Vejo que o PR foi fechado devido a alguns problemas de dependência.
As senhas de aplicativo ainda são válidas (por enquanto), mas o OAuth seria bom.
Email do Google: tldr - use oauth2 após setembro de 2024
A partir de 30 de setembro de 2024, as contas do Google Workspace permitirão o acesso apenas a aplicativos que usam OAuth. O acesso baseado em senha (com exceção das senhas de aplicativo) não será mais suportado. POP e IMAP NÃO serão descontinuados e ainda poderão ser ativados com aplicativos que se conectam usando OAuth.
Prezado Administrador,
Estamos escrevendo para informar que, como compartilhamos anteriormente neste post do blog, desativaremos o acesso a aplicativos menos seguros (LSA) — aplicativos que não são do Google e que podem acessar contas do Google apenas com nome de usuário e senha (autenticação básica) — a partir de 15 de junho de 2024.
O que você precisa saber?
O acesso por meio de autenticação básica torna as contas mais vulneráveis a tentativas de sequestro. Doravante, apenas aplicativos que suportam um método de acesso mais moderno e seguro chamado OAuth poderão acessar as contas do Google Workspace.
O acesso a LSAs será desativado em duas etapas:
A partir de 15 de junho de 2024 — As configurações de LSA serão removidas do Admin console e não poderão mais ser alteradas. Usuários habilitados poderão se conectar após essa data, mas usuários desabilitados não poderão mais acessar LSAs. Isso inclui todos os aplicativos de terceiros que exigem acesso apenas por senha ao Gmail, Google Agenda, Contatos por meio de protocolos como CalDAV, CardDAV, IMAP, SMTP e POP. As configurações de ativação/desativação do IMAP serão removidas das configurações do Gmail dos usuários. Se você usou LSAs antes desta data, poderá continuar a usá-los até 30 de setembro de 2024.
A partir de 30 de setembro de 2024 — O acesso a LSAs será desativado para todas as contas do Google Workspace. CalDAV, CardDAV, IMAP e POP não funcionarão mais ao fazer login apenas com a senha — você precisará fazer login com um tipo de acesso mais seguro chamado OAuth.
O que você precisa fazer?
Para que seus usuários finais continuem usando esses tipos de aplicativos com suas contas do Google Workspace, eles devem mudar para um tipo de acesso mais seguro chamado OAuth (uma lista de usuários afetados está anexada). Este método de autenticação permite que os aplicativos acessem as contas com uma chave digital em vez de exigir que o usuário revele seu nome de usuário e senha. Recomendamos que você compartilhe as instruções do usuário (neste arquivo PDF) com os indivíduos em sua organização para ajudá-los a fazer as alterações necessárias. Alternativamente, se sua organização estiver usando ferramentas personalizadas, você pode pedir ao desenvolvedor da ferramenta para atualizá-la para usar OAuth. As instruções para desenvolvedores também estão neste arquivo PDF.
Configuração de MDM
Se sua organização usa um provedor de gerenciamento de dispositivos móveis (MDM) para configurar perfis IMAP, CalDAV CardDAV ou POP, esses serviços serão descontinuados de acordo com o cronograma abaixo:
A partir de 15 de junho de 2024 — O push de MDM de IMAP, CalDAV, CardDAV e POP baseado em senha não funcionará mais para clientes que tentarem se conectar pela primeira vez. Se você usa Google MDM, não poderá ativar as configurações de “Configuração de Push Personalizada” para CalDAV e CardDAV.
A partir de 30 de setembro de 2024 — O push de MDM de IMAP, CalDAV, CardDAV e POP baseado em senha não funcionará mais para usuários existentes. Os administradores precisarão fazer o push de uma Conta Google usando seu provedor de MDM, o que adicionará novamente suas contas Google aos dispositivos iOS usando OAuth. Se você usa Google MDM, “Configuração de push personalizada - CalDAV” e “Configuração de push personalizada - CardDAV” (mais detalhes sobre as configurações aqui) deixarão de ser eficazes.
Outros aplicativos menos seguros
Para qualquer outro LSA, peça ao desenvolvedor do aplicativo que você está usando para começar a suportar OAuth.
Scanners e outros dispositivos
Para scanners ou outros dispositivos que usam o protocolo de transferência de e-mail simples (SMTP) ou LSAs para enviar e-mails, configure para usar OAuth, use um método alternativo ou configure uma Senha de Aplicativo para uso com o dispositivo. Se você substituir seu dispositivo, procure um que envie e-mails usando OAuth.
Nós planejamos trabalhar nisso antes do prazo que o Google forneceu, não queremos perder a pesquisa POP3 e estamos acompanhando internamente. É bastante decepcionante que o PR do net-pop tenha sido bloqueado.
Esperamos que possamos chegar a alguma solução, vejo que alguém da Meta postou naquele PR, eu também postarei, talvez possamos ter algum movimento naquele PR, caso contrário, teremos que encontrar alguma alternativa, como usar monkey-patching em Net::POP3 no core do Discourse.
!