Las comunidades de Discourse ahora pueden permitir que los usuarios inicien sesión mediante un código corto enviado por correo electrónico en lugar de un enlace mágico, ofreciendo un flujo de inicio de sesión sin contraseña que resulta familiar para muchas otras plataformas SaaS y que funciona junto con tu configuración actual de segundo factor.
En este tema, revisaremos los cambios principales y compartiremos cómo puedes empezar a utilizarlo hoy mismo.
Qué ha cambiado
Cuando esta función está habilitada, los miembros ven un flujo más sencillo:
Introducen una dirección de correo electrónico y hacen clic en Continuar.
Un código de seis dígitos llega a su bandeja de entrada. Lo pegan (o lo escriben) y el formulario se envía automáticamente cuando se completa el último dígito.
Si tienen habilitada la autenticación de segundo factor (TOTP, códigos de respaldo o clave de seguridad), aparecerá a continuación el paso estándar de 2FA.
Hay algunos detalles que vale la pena conocer: los códigos son válidos durante 10 minutos, caducan tras 5 intentos fallidos y solo pueden canjearse una vez.
Activar los códigos de inicio de sesión de un solo uso en tu comunidad
¡Por ahora, esto se considera un cambio experimental! Antes de implementarlo de forma más amplia, estamos deseando recibir tus comentarios para ayudarnos a realizar mejoras.
Para activarlo, dirígete a la página Cambios próximos en tu área de administración (/admin/config/upcoming-changes) y busca el elemento Habilitar inicios de sesión locales mediante código. Actualiza el campo Habilitado para… para que tu sitio opte por este nuevo diseño:
Antes de habilitarlo, confirma que tanto enable_local_logins como enable_local_logins_via_email también estén establecidos en true, ya que la función no puede activarse sin ellos. Si estás utilizando DiscourseConnect (enable_discourse_connect), esta función no puede habilitarse.
Una vez que el cambio esté habilitado, la ruta de inicio de sesión mediante código aparecerá automáticamente.
¿Qué opinas?
Ahora te toca a ti: nos encantaría saber qué opinas de esta nueva función. ¿Qué te gusta y qué no? ¿Qué funciona bien y qué se podría mejorar?
Acabo de probarlo en mi sitio. No estoy seguro de lo que piensan los demás, pero esto parece una degradación bastante grande para mí como usuario de un gestor de contraseñas…
Este nuevo flujo elimina la estrategia actual de «generar correo electrónico, escribir nombre de usuario, generar contraseña, guardar» en la que mi gestor de contraseñas me ha llevado y te obliga a escribir el correo electrónico primero antes de todo. No tengo ningún problema con lo del código de correo electrónico (y de hecho casi lo prefiero, especialmente si el código está incluido en el asunto del correo) pero me opongo firmemente a eliminar las otras cajas de datos de la cuenta. Si fuera un usuario sin ningún conocimiento técnico, también me vería en la situación de no entregar mi correo electrónico a una caja sin información como esta porque no es un diseño común. Antes de que esto se convierta en algo permanente, sería genial que se volviera a añadir.
Los códigos por correo electrónico, también conocidos como “enlaces mágicos”, son una opción decente, pero orientar a los usuarios hacia el uso de claves de acceso mejora la experiencia considerablemente.
Uno de los mayores problemas con los códigos por correo electrónico es que no funcionan como uno esperaría en los navegadores integrados en las aplicaciones, incluido el navegador integrado de Gmail.
Probablemente el problema más común que encuentran las personas con los enlaces mágicos es que creen haber iniciado sesión en el sitio web en su navegador habitual, pero en realidad lo han hecho a través de un navegador integrado en la aplicación. Por ejemplo, alguien podría recibir el enlace de inicio de sesión en su correo electrónico. Abre la aplicación de Gmail, hace clic en el botón “Iniciar sesión en 404 Media” y su teléfono carga la página web. Pero esto carga el sitio web en el navegador web de Gmail, no en su navegador Safari nativo.
Las claves de acceso solucionan este problema.
Para empezar, los sitios web que utilizan enlaces mágicos pueden ofrecer las claves de acceso como una función opcional para los clientes que se han quejado de cómo funcionan sus enlaces mágicos actualmente. Para garantizar que no cause problemas, como una especie de lanzamiento suave, podrían hacer que la función sea 100 % optativa.
Un poco más adelante, una vez que las personas que gestionan el sitio web estén convencidas de que las claves de acceso realmente ayudan con los problemas de experiencia de usuario relacionados con los enlaces mágicos, pueden sugerir a los usuarios que añadan claves de acceso después de iniciar sesión, una vez cada 90 días aproximadamente, o cada vez que inicien sesión utilizando la función de inicio de sesión entre dispositivos de las claves de acceso. La forma de presentar dicha sugerencia podría ser algo como esto para los usuarios de dispositivos Apple: ¿Quieres evitar tener que revisar tu correo electrónico la próxima vez? Configura una clave de acceso para usar Face ID o Touch ID e iniciar sesión de forma rápida y segura.
¡Me encanta este enfoque! Sin embargo, me molesta un poco que no se pueda cambiar el nombre de visualización antes de finalizar el registro. Creo que sería genial añadir una opción para cambiarlo durante el proceso.
En mi comunidad, he desactivado la configuración del sitio Prioritize username in UX, lo que significa que el nombre completo/nombre de visualización tiene prioridad en toda la interfaz de usuario. Debido a esto, los nombres asignados automáticamente como “user21” se ven bastante mal en la interfaz si el usuario no tiene una opción inmediata para personalizarlos.
Este nuevo flujo no envía un enlace mágico. Solo envía el código. El usuario permanece en la misma página y copia/pega el código desde su correo electrónico al formulario de registro. Por lo tanto, este nuevo enfoque sí ayuda con los navegadores integrados de las aplicaciones (es una de las principales ventajas del cambio).
Sin duda, esto es algo que nos gustaría hacer a continuación, en el paso de contraseña del registro. Las aplicaciones y sitios web han incrementado su compatibilidad con las claves de acceso, y sigo viendo este incentivo en muchos contextos, por lo que tiene sentido añadirlo también a Discourse. (La masa crítica de compatibilidad es muy útil en esta transición de contraseñas a claves de acceso.)
Mi único problema con esta función es que elimina los campos de nombre y nombre de usuario de mi página de registro. ¿Es esto intencionado? No quiero obligar a los usuarios a buscar por todos lados en la configuración justo después de registrarse solo para establecer un nombre de usuario que no sea “user63”.
Sin este cambio, los enlaces «He olvidado mi contraseña» y «Envíame un correo» tenían el mismo tamaño. Ahora el segundo es más grande. ¿Es intencional?
Qué ha cambiado
Activar los códigos de inicio de sesión de un solo uso en tu comunidad
Antes de habilitarlo, confirma que tanto 
¿Qué opinas?
