Registro de cuenta más fácil con códigos de correo

[rishabh]

Las comunidades de Discourse ahora pueden permitir a los usuarios iniciar 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 existente de segundo factor.

En este tema, repasaremos los cambios principales y compartiremos cómo puedes comenzar a usarlo hoy.

Qué ha cambiado

Cuando esta función está habilitada, los miembros ven un flujo más simple:

:

1. Ingresan una dirección de correo electrónico y hacen clic en Continuar.
2. 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.
3. Si tienen habilitada la autenticación de segundo factor (TOTP, códigos de respaldo o clave de seguridad), aparece a continuación el paso estándar de 2FA.

Algunos detalles que vale la pena conocer: los códigos son válidos durante 10 minutos, expiran tras 5 intentos fallidos y solo pueden canjearse una vez.

Activar 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 manera más amplia, estamos acogiendo tus comentarios para ayudarnos a realizar mejoras.

Para activarlo, ve 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 se inscriba en este nuevo diseño:

Antes de habilitarlo, confirma que tanto enable_local_logins como enable_local_logins_via_email también sean true, ya que la función no se puede activar sin ellos. Si estás usando DiscourseConnect (enable_discourse_connect), no se puede habilitar esta función.

Una vez que el cambio esté habilitado, la ruta de inicio de sesión con código aparecerá automáticamente.

Nombres de usuario aleatorios opcionales para nuevas cuentas

Puedes dar a los nuevos miembros que se registran sin un nombre de usuario reconocible en su correo electrónico un nombre generado amigable como “QuietFalcon42” en lugar de un marcador genérico como user1.

Si haces clic en Mostrar ajustes relacionados para este cambio próximo y habilitas el ajuste de sitio enable_random_usernames, el paso de cuenta lista prellenará la sugerencia e incluirá un botón de dado para generar uno nuevo:

Las listas de palabras detrás de las sugerencias son configurables mediante los ajustes de sitio random_username_adjectives y random_username_nouns, por lo que las comunidades pueden ajustarlas a su tono o idioma.

¿Qué opinas?

Te toca a ti: nos encantaría saber qué piensas de esta nueva función. ¿Qué te gusta y qué no; qué está funcionando bien y qué podría mejorarse?

[darkpixlz (Pyx)]

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.

[dfabulich (Dan Fabulich)]

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.

Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

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.

Orientar a los usuarios hacia las claves de acceso es lo mismo que orientarlos hacia el uso de un gestor de contraseñas, porque las claves de acceso son simplemente contraseñas que requieren un gestor de contraseñas.

[Don]

Hola

¡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.

¡Gracias!

[pmusaraj (Penar Musaraj)]

@dfabulich

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 de las aplicaciones, incluido el navegador integrado de Gmail.

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).

@dfabulich

Incentivar a los usuarios a usar claves de acceso (passkeys)

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.)

[DomMcD (Dominic McDevitt)]

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”.

[kddkd (16)]

¡Este método de registro con código de verificación por correo electrónico es un cambio que siempre he deseado!

[Moin]

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?

[Moin]

Se ha corregido en

UX: Match font size of one-time code login link (#41879)

[rishabh]

Gracias por los comentarios, sí, es intencional como parte de una forma más rápida de crear cuentas.

@DomMcD

No quiero obligar a los usuarios a buscar en la configuración justo después de registrarse solo para establecer un nombre de usuario que no sea “user63”.

Tomado nota, sí, estamos explorando ideas para hacer este siguiente paso más sencillo o para establecer nombres de usuario iniciales utilizando un método diferente.

[Moin]

Estoy de acuerdo. Esos nombres de usuario genéricos hacen que la interacción con los usuarios sea más confusa. Dado que los usuarios tienen solo 3 días para actualizar sus nombres, espero que a menudo se den cuenta después de que haya pasado ese tiempo, por lo que el personal debe encargarse de renombrarlos.
Me gustó mucho que Offering blank username suggestions rather than ‘UserN’ at signup evitara que eso ocurriera, por ejemplo, aquí en meta. El último usuarioXXX se creó el 7 de enero, antes de que se integrara esa corrección. Luego no hubo ningún nuevo usuarioXXX hasta que se habilitó esta función, y desde entonces hay 12 nuevos.

[Thomas_Rother (Thommie Rother)]

Esta función es extremadamente útil. Cada vez más plataformas utilizan la función de «código único por correo electrónico» para ofrecer inicios de sesión seguros con MFA, sin necesidad de tener a mano un dispositivo específico (con el autenticador correspondiente).

[rishabh]

@DomMcD

No quiero obligar a los usuarios a buscar a ciegas en la configuración justo después de registrarse solo para establecer un nombre de usuario que no sea «user63».

@Moin

Estoy de acuerdo. Esos nombres de usuario genéricos hacen que la interacción con los usuarios sea más confusa. Dado que, por defecto, los usuarios solo tienen 3 días para actualizar sus nombres, me espero que a menudo se den cuenta después de que ese tiempo haya pasado, por lo que el personal debe encargarse de cambiarlos.

¿No ves esta etapa durante la creación de la cuenta?

[Moin]

Esta es una cita extraña: parece que DomMcD me ha citado, lo cual no es cierto.

No he probado los pasos. Estaba comentando sobre lo que he observado respecto a los nuevos usuarios aquí en Meta. No me importa si veo un campo durante el registro. Tengo que lidiar con lo que los demás hacen con ese campo.

También me pregunto cómo se manejan los nombres. Aunque no todos los usuarios parecen usar los nombres de usuario generados, noto que aún más tienen un nombre que es userXXX.

Parece que obtienen eso incluso al cambiar el nombre de usuario, y esto resulta en que se use el mismo número una y otra vez hasta que el nombre de usuario está ocupado, y entonces vuelve a empezar con el siguiente número.

Por ejemplo, 0102100988082, mohamedasarudeen y user603 todos tienen user603 como su nombre.

Sé que podrían cambiar el nombre, pero, de nuevo, no puedo cambiar mi experiencia al interactuar con ellos.

[rishabh]

Gracias a todos por los informes. Una corrección se integrará muy pronto:

FIX: Stop placeholder usernames sticking after email code signup (#42796)

[rishabh]

Actualización

Gracias al último trabajo de @keegan, ahora tenemos una función de generación de nombres de usuario en esta etapa que prellena una sugerencia:

@rishabh

Nombres de usuario aleatorios para nuevas cuentas

Los nuevos miembros que se registran sin un nombre de usuario reconocible en su correo electrónico ahora reciben un nombre generado amigable como «QuietFalcon42» en lugar de un marcador genérico como user1. La etapa de cuenta lista prellena la sugerencia e incluye un botón de dados para generar uno nuevo.

Las listas de palabras detrás de las sugerencias son configurables a través de las configuraciones del sitio random_username_adjectives y random_username_nouns, por lo que las comunidades pueden ajustarlas a su tono o idioma. Para desactivar esta función y mantener el respaldo numérico antiguo, deshabilita enable_random_usernames.

[Jagster (Jakke Flemming)]

Una solicitud de UX, si es posible. Esta:

Mis dispositivos están bastante seguros de que aquí se necesita una contraseña, pero debería pedir el correo electrónico. Así, mis teléfonos y otros dispositivos sabrían que deben ofrecer una dirección en lugar de otras credenciales.

[thisisjoshjones (Joshua Jones)]

¿Podría implementarse este flujo de registro también en la página de aterrizaje de invitaciones? Estoy seguro de que eso está fuera del alcance de esta fase alfa, pero esa implementación sería muy útil una vez que la función sea estable. Esto realmente reduce la barrera de entrada para los miembros de mi comunidad, ¡así que gracias!

[mcwumbly (Dave McClure)]

Por coincidencia, hay algunos trabajos en curso al respecto aquí:

FEATURE: Use email code for invites (#43138)

[ecki (Bernd)]

Me gusta la función en general (primer paso de registro solo con correo electrónico y código), pero tiene algunos detalles por pulir:

a) el inicio de sesión y el registro deberían tener configuraciones separadas.
b) ocultar el campo de nombre de usuario en el formulario de registro debería ser una opción adicional, ya que los nombres de usuario siguen siendo una función de comunicación importante; los nombres de usuario aleatorios o basados en un contador se ven bastante extraños.
c) curiosamente, los nombres de usuario aleatorios funcionaron en mi sitio para algunos registros de spam (entradas de usuarios no verificados), pero no para dos usuarios reales, a ambos se les asignaron los nombres «user1» y «user2», qué horror. (No estoy seguro de cuál sea la diferencia entre los spammers y los usuarios).
d) ¿podría ser un botón adicional para el inicio de sesión, tal vez uno que envíe un correo electrónico con un enlace mágico y un código? No veo la necesidad de separar esto.
e) la documentación debería dejar claro que elimina el formulario de nombre de usuario (o mejor aún, que no lo elimine).