Deshabilitar la verificación de correo electrónico para SSO

Hola,

He configurado Discourse para que utilice Auth0 como proveedor de SSO. El problema que tengo es que, cuando un usuario se registra, recibe dos correos de verificación: uno de Auth0 y otro de Discourse.

¿Hay alguna manera de desactivar el de Discourse?

Gracias de antemano.

Si las direcciones de correo electrónico están siendo verificadas por Auth0, puedes desactivar los correos electrónicos de verificación de Discourse seleccionando la configuración del sitio oauth2 email verified. Hay una referencia a esa configuración en esta publicación: Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin - #33 by blake.

Gracias por la respuesta @simon, pero estoy usando SSO, no OAuth2.

El término SSO se utiliza para varios métodos de autenticación diferentes. Esto ha causado confusión en varias ocasiones en el pasado.

Si estás utilizando la implementación de SSO de Discourse, la verificación de correo electrónico se controla mediante el parámetro de SSO require_activation. Establece ese parámetro en "false" para omitir la verificación de correo electrónico.

Gracias de nuevo, @simon.

Quiero evitar desactivarlo por completo. Por ahora, lo tengo configurado de modo que require_activation devuelva true o false según si han sido verificados por Auth0. Esto funciona bien y, después de que hagan clic en el correo de Auth0, la próxima vez que inicien sesión quedarán verificados en Discourse.

Así que, idealmente, bastaría con suprimir el correo, a menos que esté pasando por alto algo.

Eso tiene sentido. Nuestro plugin de WordPress gestiona la verificación de correo electrónico de la misma manera.

Si quieres ver cómo utiliza Discourse el valor de require_activation, echa un vistazo a este archivo: https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L81. Verás que cuando require_activation se establece en "false" al crear un usuario por primera vez mediante SSO, Discourse crea un usuario activo. Si se establece en "true", el usuario no se activará hasta que haga clic en el enlace del correo de activación de Discourse.

Una vez que un usuario se establece como active en Discourse, lo único que debería hacer que un usuario necesite ser reactivado es si has habilitado la configuración del sitio sso_overrides_email y el usuario actualiza su dirección de correo electrónico en tu sitio proveedor de SSO.

Cuando se establece en "true", require_activation también impide que Discourse vincule usuarios existentes con usuarios de tu sitio externo basándose en su dirección de correo electrónico. Esto puede causar problemas cuando se implementa SSO después de que los usuarios ya hayan sido creados en el sitio mediante cuentas con nombre de usuario y contraseña.

Gracias, tiene sentido. Sin embargo, no estoy seguro de cómo esto evita que se envíe el correo de “verificar correo electrónico” de Discourse.

Solo quiero que se envíe el de Auth0.

Para que el correo de verificación se envíe únicamente desde el sitio de tu proveedor de SSO, los usuarios deberán registrarse en ese sitio y verificar su dirección de correo electrónico antes de iniciar sesión por primera vez en Discourse. A continuación, podrás establecer el parámetro require_activation en "false" para esos usuarios. Se crearán como usuarios activos en Discourse y no recibirán el correo de activación de Discourse.

Esto no tiene sentido. ¿Cómo puedo hacer que verifiquen su correo electrónico antes del primer inicio de sesión en Discourse?

Mi sitio web ya se encarga de las verificaciones de correo electrónico. ¿Cómo puedo desactivar que Discourse envíe correos de verificación, pero seguir mostrando al usuario un mensaje que indique que necesita autenticarse?

DiscourseConnect asume que estás validando las direcciones de correo electrónico en tu sitio web. Siempre que lo hagas, no establezcas el parámetro require_activation en la carga útil del SSO. Si ese parámetro no está presente en la carga útil, los usuarios iniciarán sesión en Discourse sin que se les envíe un correo electrónico de activación.

Sí, pero entonces Discourse asumirá que están validados, lo cual podría no ser cierto si el usuario fue al foro y olvidó o decidió no validar su correo electrónico. Si el sitio web establece require_validation en true, significa que el usuario aún no ha validado su correo en el sitio web, pero definitivamente recibió un enlace de validación, por lo que no sería necesario que Discourse lo envíe de nuevo; sin embargo, lo hará debido a este parámetro.

Básicamente, el problema solo surge si el usuario accede a Discourse antes de validar. Por lo tanto, en este momento básicamente tengo que elegir entre dos opciones:

  1. El usuario recibe solo un correo de validación, pero Discourse lo tratará como validado, lo cual no es ideal, ya que podrían no completar la validación.
  2. El usuario recibe dos correos de validación, pero será correctamente validado tanto por el foro como por el sitio web. Esta opción tampoco es ideal, pero definitivamente es la mejor de las dos.

Existe una tercera opción: agregar un interruptor que funcione solo si SSO está habilitado, desactivando el correo de verificación de Discourse (pero dejando una página de error que indique al usuario que no está verificado).

Idealmente, cuando un usuario crea una cuenta en tu sitio web, validarás su dirección de correo electrónico solicitando que responda a un correo de activación enviado desde tu sitio web cuando el usuario se registra. Si, por alguna razón, permites que los usuarios creen cuentas en tu sitio web antes de haber validado su dirección de correo electrónico, puedes establecer el parámetro require_validation de forma condicional en la carga útil (payload) de SSO. Si el usuario ha validado su dirección de correo electrónico, establece require_validation en false, o simplemente omite el parámetro de la carga útil. Si el usuario no ha validado su dirección de correo electrónico en tu sitio web, establece el parámetro require_activation en true para que se les envíe un correo de activación desde Discourse.

Eso es exactamente lo que estoy haciendo y es un problema. Por ejemplo, un usuario se registra, recibe un correo de activación desde el sitio web, pero en lugar de abrirlo y activar su cuenta, decide ir a Discourse, ¿por qué no? Entonces, require_activation se establecerá en true, porque el usuario aún no ha sido activado. Pero Discourse decidirá que el usuario necesita otro correo de activación, lo cual es un problema, ya que ya hay un correo de activación del sitio web esperando ser abierto. Discourse debería simplemente mostrar un mensaje de error indicando que el usuario debe revisar su correo.