Agregar soporte de autenticación más completo para POP3

Eso es genial, TLS también es un requisito para Exchange Online. Pero aún así, la autenticación se realiza mediante autenticación básica (si entiendo bien el siguiente código, no hay forma de elegir entre ningún otro mecanismo de autenticación como OAuth2) discourse/poll_mailbox.rb at tests-passed · discourse/discourse (github.com)

Rastreando un poco más, parece que la biblioteca Class: Net::POP3 (Ruby 2.7.0) (ruby-doc.org) en Ruby no admite la autenticación OAuth2, solo la básica.

Para referencia:

Simplemente espera un usuario y una contraseña, en lugar de un usuario y un token, además de que necesitaría usar el formato AUTH XOAUTH2 para codificar y transmitir el token.

Disculpas si no fui claro en mi pregunta, pero estoy preguntando más sobre tener un enfoque similar al de los siguientes ejemplos:

Estos enfoques permitirán a Discourse conectarse a POP3 (y, por lo tanto, a IMAP) con autenticación OAuth2, cumpliendo así los requisitos para MS y probablemente para GMail en el futuro cercano si no ahora (OAuth 2.0 Mechanism | Gmail IMAP | Google Developers).

11 Me gusta

Creo que esta es una solicitud de característica muy buena y apoyo totalmente la adición de compatibilidad con OAuth2 a POP3.

Sin embargo, no puedo comprometerme a cuándo podremos implementarlo, pero si surgiera una PR, sin duda priorizaríamos su revisión y fusión.

10 Me gusta

¡Genial, muchas gracias! :clap:

¡Espero ver esta función pronto!

1 me gusta

Según tengo entendido, Google/Gmail desactivó la autenticación POP3 que no fuera OAuth el 30 de mayo. Por lo tanto, ya no puedo recuperar correos electrónicos a través de POP3. Sería genial si Discourse admitiera OAuth2.

No pude encontrar ningún otro tema aparte de este. ¿Soy el único que usa Gmail con Discourse?

1 me gusta

Aún puedes usar una contraseña de aplicación para autenticarte en Gmail a través de POP3. Aquí tienes un tema reciente relevante:

4 Me gusta

Solo para aquellos interesados en el tema, hay una PR abierta por nuestro colega @acosenza, ¡se agradecen los comentarios!

3 Me gusta

… y un enfoque alternativo totalmente funcional proporcionado a través de un plugin, como se explica en Microsoft Graph Mail Poller - plugin - Discourse Meta

¡Espero que esto despierte el interés de la comunidad! :tada:

4 Me gusta

Bump porque Google también está a punto de desconectar las cuentas de Workspace.

Veo que la PR se cerró debido a problemas de dependencia.
Las contraseñas de aplicación siguen siendo válidas (por ahora), pero el OAuth sería bueno.

Correo de Google: tldr - usar oauth2 después de septiembre de 2024

Logotipo de Google Workspace

A partir del 30 de septiembre de 2024, las cuentas de Google Workspace solo permitirán el acceso a aplicaciones que utilicen OAuth. El acceso basado en contraseñas (con la excepción de las contraseñas de aplicación) ya no será compatible. POP e IMAP NO desaparecerán y aún se podrán habilitar con aplicaciones que se conecten usando OAuth.

Estimado administrador:

Le escribimos para informarle que, como compartimos previamente en esta publicación de blog, desactivaremos el acceso a aplicaciones menos seguras (LSA), que son aplicaciones no pertenecientes a Google que pueden acceder a cuentas de Google solo con un nombre de usuario y contraseña (autenticación básica), a partir del 15 de junio de 2024.

¿Qué necesita saber?

El acceso a través de la autenticación básica hace que las cuentas sean más vulnerables a intentos de secuestro. En el futuro, solo las aplicaciones que admitan un método de acceso más moderno y seguro llamado OAuth podrán acceder a las cuentas de Google Workspace.

El acceso a las LSA se desactivará en dos etapas:

  1. A partir del 15 de junio de 2024: Se eliminarán los ajustes de LSA de la consola de administración y ya no se podrán modificar. Los usuarios habilitados podrán conectarse después de esa fecha, pero los usuarios deshabilitados ya no podrán acceder a las LSA. Esto incluye todas las aplicaciones de terceros que requieren acceso solo con contraseña a Gmail, Google Calendar y Contactos a través de protocolos como CalDAV, CardDAV, IMAP, SMTP y POP. Los ajustes de habilitación/deshabilitación de IMAP se eliminarán de los ajustes de Gmail de los usuarios. Si ha estado utilizando LSA antes de esta fecha, puede seguir utilizándolas hasta el 30 de septiembre de 2024.
  2. A partir del 30 de septiembre de 2024: Se desactivará el acceso a las LSA para todas las cuentas de Google Workspace. CalDAV, CardDAV, IMAP y POP ya no funcionarán al iniciar sesión solo con contraseña; deberá iniciar sesión con un tipo de acceso más seguro llamado OAuth.

¿Qué necesita hacer?

Para que sus usuarios finales puedan seguir utilizando este tipo de aplicaciones con sus cuentas de Google Workspace, deben cambiar a un tipo de acceso más seguro llamado OAuth (se adjunta una lista de usuarios afectados). Este método de autenticación permite a las aplicaciones acceder a las cuentas con una clave digital en lugar de requerir que un usuario revele su nombre de usuario y contraseña. Le recomendamos que comparta las instrucciones para el usuario (en este archivo PDF) con las personas de su organización para ayudarles a realizar los cambios necesarios. Alternativamente, si su organización utiliza herramientas personalizadas, puede pedirle al desarrollador de la herramienta que la actualice para que utilice OAuth. Las instrucciones para desarrolladores también se encuentran en este archivo PDF.

Configuración de MDM

Si su organización utiliza un proveedor de administración de dispositivos móviles (MDM) para configurar perfiles IMAP, CalDAV, CardDAV o POP, estos servicios se eliminarán gradualmente según el siguiente cronograma:

  1. A partir del 15 de junio de 2024: El envío de IMAP, CalDAV, CardDAV y POP basado en contraseñas a través de MDM ya no funcionará para los clientes que intenten conectarse por primera vez. Si utiliza Google MDM, no podrá activar los ajustes de “Configuración de envío personalizada” para CalDAV y CardDAV.
  2. A partir del 30 de septiembre de 2024: El envío de IMAP, CalDAV, CardDAV y POP basado en contraseñas a través de MDM ya no funcionará para los usuarios existentes. Los administradores deberán enviar una Cuenta de Google utilizando su proveedor de MDM, lo que volverá a agregar sus cuentas de Google a los dispositivos iOS utilizando OAuth. Si utiliza Google MDM, “Configuración de envío personalizada - CalDAV” y “Configuración de envío personalizada - CardDAV” (más detalles sobre los ajustes aquí) dejarán de ser efectivos.

Otras aplicaciones menos seguras

  • Para cualquier otra LSA, pida al desarrollador de la aplicación que está utilizando que empiece a admitir OAuth.

Escáneres y otros dispositivos

Para escáneres u otros dispositivos que utilizan el protocolo simple de transferencia de correo (SMTP) o LSA para enviar correos electrónicos, configúrelos para usar OAuth, utilice un método alternativo o configure una contraseña de aplicación para usarla con el dispositivo. Si reemplaza su dispositivo, busque uno que envíe correos electrónicos utilizando OAuth.

2 Me gusta

Dado que la PR está bloqueada por la PR de net-pop upstream, ¿existen soluciones alternativas conocidas para las cuentas alojadas en GSuite?

1 me gusta

¿Quizás @team puede darnos una actualización sobre los planes para esta función?

1 me gusta

En primer lugar, quiero agradecer a Ismael y a tu colega Alessio por el trabajo preliminar que han realizado hasta ahora, especialmente con Add OAUTH2 support by AlessioC31 · Pull Request #16 · ruby/net-pop · GitHub.

Tenemos previsto trabajar en esto antes de la fecha límite que ha proporcionado Google, no queremos perder la sondeo POP3 y lo estamos rastreando internamente. Es bastante decepcionante que el PR de net-pop se haya bloqueado.

Espero que podamos llegar a alguna solución, veo que alguien de Meta ha publicado en ese PR, yo también lo haré, tal vez podamos conseguir algún avance en ese PR, de lo contrario, tendremos que encontrar alguna alternativa como el “monkey-patching” de Net::POP3 en el núcleo de Discourse.

4 Me gusta

Hola, ¿hay algún avance en este tema? Ya que la fecha límite de Google se acerca…

Descubrimos que, en realidad, todavía no hay nada que hacer. Google seguirá admitiendo Contraseñas de Aplicaciones según los siguientes artículos:

Por lo tanto, lo único que debe hacer si está utilizando SMPT/POP3 con Discourse y Google es asegurarse de que está utilizando una Contraseña de Aplicación de Google.

5 Me gusta