Creo que esto ya funciona si no tienes SSO: un usuario que es invitado por correo electrónico no necesita activar su correo electrónico, ya que el enlace del correo electrónico en sí cuenta como la activación.
Sin embargo, estoy usando WordPress como SSO y si invito a alguien, hay un proceso laborioso de ser enviado primero a la pantalla de inicio de sesión, tener que hacer clic en registrarse, completar el formulario, luego necesitar validar mi correo electrónico, y luego, cuando finalmente llegas al foro, tienes que hacer clic en “iniciar sesión”, todo antes de poder entrar.
¿Hay alguna manera de que pueda:
Hacer que el enlace de invitación vaya por defecto a mi página de Registro, no a la página de inicio de sesión
Omitir la necesidad de activar el correo electrónico
Oye, no, disculpa la confusión, me refiero a usar el sistema de invitaciones de Discourse.
Quiero animar a la gente a invitar a sus amigos y obtener las insignias relacionadas con eso. Pero actualmente el proceso de registro es muy tedioso después de ser invitado.
También, para tu información, lo configuré para que las personas invitadas fueran TL1, pero ignoró eso en mis pruebas y lo estableció en TL0.
Por lo que entiendo, actualmente no es posible que un cliente de proveedor de DiscourseConnect distinga entre una solicitud de inicio de sesión que se origina en una invitación y una solicitud de inicio de sesión que se origina en un inicio de sesión normal. En otras palabras, así es como funciona
El usuario A crea una invitación en Discourse.
El usuario B va al enlace de invitación (en Discourse).
Debido a que DiscourseConnect está configurado, Discourse redirige al usuario B a WordPress.
Actualmente, no creo que sea posible que el plugin WP Discourse distinga entre una solicitud que llega como la 3 (es decir, redirigir desde una invitación) y una solicitud que llega cuando un usuario simplemente hace clic en “iniciar sesión” en Discourse. En otras palabras, tendrías que redirigir todas las solicitudes de autenticación entrantes al registro, lo cual probablemente no es lo que quieres.
@Shauny En resumen, se necesitaría una actualización en el propio protocolo DiscourseConnect (es decir, cómo funciona en Discourse) para que el flujo de invitación funcione de la manera que deseas.
Ok. ¿Y qué pasa con el correo electrónico de verificación? Sabe que la dirección de correo electrónico fue invitada, así que ¿no puede omitir ese paso adicional?
Eliminar el correo electrónico de verificación, además de ser inseguro, tiene el mismo problema.
No hay forma de distinguir entre el escenario que usted prevé y otros escenarios del lado de Wordpress. Incluso si eso fuera posible, todavía no sería aconsejable, ya que puede compartir un enlace de invitación sin enviarlo por correo electrónico a alguien.
Por lo tanto, la redirección automática al registro puede ser posible si hay una actualización del protocolo DiscourseConnect, pero eliminar la verificación por correo electrónico probablemente no sea posible (sin comprometer la seguridad de su sitio).
Pero si envía el enlace de invitación por correo electrónico y hacen clic en el enlace del correo electrónico, ya ha verificado su dirección de correo electrónico. Si no utiliza SSO, todo esto funciona y no se requiere ninguna verificación adicional por correo electrónico.
Según entiendo, en su estado actual, no hay forma de que Discourse le diga al proveedor SSO que el correo electrónico fue verificado por una invitación, y el SSO tampoco se lo está diciendo a Discourse.
Realmente debería haber una forma de eliminar la activación por correo electrónico en el producto principal. Tengo Discourse configurado con SSO y el paso de verificación por correo electrónico está agregando mucha fricción para los nuevos usuarios.
Existe este plugin que lo desactiva pero desafortunadamente no tengo acceso para instalar plugins donde estoy alojando (y no parece funcionar para todos): Disable Email Verification for Discourse Plugin
Es bastante frustrante no poder desactivar la activación por correo electrónico y hay muchas publicaciones a lo largo de los años con diferentes personas luchando con esto. El producto principal debería permitir a los administradores ejecutar un servidor de la manera que deseen.