通过邮箱验证码更轻松地注册账户

Discourse 社区现在可以允许用户使用通过电子邮件发送的短代码进行登录,而不是使用魔法链接。这种无密码登录流程与许多其他 SaaS 平台类似,熟悉感强,并且可以与现有的二次验证设置配合使用。

在本主题中,我们将回顾主要变更,并分享如何立即开始使用此功能。

:microscope: 变更内容

启用此功能后,成员将看到更简单的流程:

:

  1. 输入电子邮件地址并点击继续
  2. 六位数字代码将发送到他们的收件箱。粘贴(或输入)该代码后,当输入最后一位数字时,表单将自动提交。
  3. 如果启用了二次身份验证(TOTP、备用代码或安全密钥),接下来将显示标准的 2FA 步骤。

一些值得了解的细节:代码有效期为 10 分钟,尝试 5 次失败后过期,且只能使用一次。

:gear: 在社区中启用一次性登录代码

目前,这被视为一项实验性变更! 在更广泛地推广之前,我们欢迎您提供反馈,以帮助我们进行改进。

要启用此功能,请前往管理区域的 即将推出的变更 页面(/admin/config/upcoming-changes),找到 Enable local logins via code(通过代码启用本地登录)项。更新 Enabled for(启用范围)… 字段,以使您的站点选择加入此新设计:

:warning: 在启用之前,请确认 enable_local_loginsenable_local_logins_via_email 也都为 true,因为如果没有它们,该功能无法启用。如果您正在使用 DiscourseConnectenable_discourse_connect),则无法启用此功能。

一旦启用该变更,代码登录路径将自动出现。

:game_die: 新账户的随机用户名

新成员如果在电子邮件中没有可识别的用户名,现在将获得一个友好的生成名称,例如 “QuietFalcon42”,而不是像 user1 这样的通用占位符。账户就绪步骤会预填建议的名称,并包含一个骰子按钮以生成新的名称。

建议背后的单词列表可以通过 random_username_adjectivesrandom_username_nouns 站点设置进行配置,因此社区可以根据其语气或语言进行调整。要退出并保留旧的数字回退方案,请禁用 enable_random_usernames

:mega: 您怎么看?

轮到你们了:我们很想听听您对这个新功能的评价。您喜欢和不喜欢的地方是什么?哪些地方运作良好,哪些地方可以改进?

10 个赞

我刚刚在我的网站上试了一下。我不确定其他人是怎么想的,但作为一个密码管理器用户,我觉得这似乎是一个相当大的降级……

这个新流程取消了我密码管理器一直采用的“生成邮箱、输入用户名、生成密码、保存”策略,并强制你先输入邮箱才能进行后续操作。我对邮箱验证码的方式没有异议(甚至几乎更喜欢这种方式,尤其是如果验证码包含在邮件主题中的话),但我强烈反对移除其他账户数据输入框。如果我是一个没有任何技术背景的用户,我也可能不会把我的邮箱输入到一个没有任何提示信息的框中,因为这种设计并不常见。在这一切成为永久改变之前,最好能把这些功能加回来。

2 个赞

电子邮件验证码,也就是所谓的“魔法链接”,表现尚可,但引导用户转向使用通行密钥(Passkeys)能让体验好上不止一个档次。

电子邮件验证码最大的问题之一在于,它们在应用内浏览器(包括 Gmail 的应用内浏览器)中无法发挥预期的作用。

人们在处理魔法链接时遇到的最常见问题大概是:他们以为自己已在普通浏览器中登录了网站,但实际上却是通过应用内浏览器登录的。例如,某人可能收到了登录链接的电子邮件。他们打开 Gmail 应用,点击“登录 404 Media”按钮,手机随即加载网页。但这实际上是在 Gmail 的内置浏览器中加载网站,而非原生 Safari 浏览器。

通行密钥可以解决这一问题。

起初,使用魔法链接的网站可以将通行密钥设为一项可选功能,供那些抱怨当前魔法链接使用体验的客户选择启用。为确保不会引发任何问题,作为一种软启动策略,该功能可以设为完全由用户主动选择启用。

稍后,当网站运营人员确信通行密钥确实有助于改善围绕魔法链接的用户体验问题时,他们可以在用户登录之后,每隔约 90 天,或每当用户使用通行密钥的跨设备登录功能时,提示用户添加通行密钥。针对苹果设备用户,此类提示的措辞可以类似如下:想避免下次再查看电子邮件吗?设置通行密钥,以便使用 Face ID 或 Touch ID 快速安全地登录。

引导用户转向使用通行密钥,与引导用户转向使用密码管理器是如出一辙的,因为通行密钥本质上就是需要密码管理器支持的密码

2 个赞

你好 :waving_hand:

我非常喜欢这种方法!不过,有一点让我有些困扰,即在注册完成之前无法更改显示名称。我认为在注册过程中增加一个更改显示名称的选项会非常好。

在我的社区中,我禁用了“在用户体验中优先显示用户名”这一站点设置,这意味着在界面上会优先显示全名/显示名称。因此,如果用户没有立即自定义名称的选项,自动分配的名称如“user21”在前端看起来会非常糟糕。

谢谢!

6 个赞

这个新流程不会发送魔法链接,仅发送验证码。用户停留在同一页面,并将电子邮件中的验证码复制粘贴到注册表单中。因此,这种新方法确实有助于解决内嵌浏览器的问题(这是此次变更的主要优势之一)。

这确实是我们接下来希望在注册密码步骤中实现的功能。应用程序和网站对通行密钥的支持力度正在加大,我在许多场景中都能看到引导使用通行密钥的提示,因此将其添加到 Discourse 中也合乎情理。(从密码切换到通行密钥的过程中,达到关键支持量是非常有帮助的。)

3 个赞

我对这个功能唯一的不满是,它从我的注册页面中移除了姓名和用户名字段。这是有意为之吗?我可不想在用户刚注册完就迫使他们去设置里翻找,只为了把用户名从“user63”改成别的。

3 个赞

这个邮箱验证码注册方式是我一直希望有的改变!

1 个赞

如果不进行此项更改,“我忘记了密码”和“发送邮件给我”链接的大小是相同的。现在后者更大。这是故意的吗?

4 个赞

该问题已在
UX: Match font size of one-time code login link - Pull Request #41879 - discourse/discourse - GitHub 中修复

4 个赞

感谢反馈,是的,这是有意为之,作为更快创建账户方式的一部分。

已记录。是的,我们正在探索各种想法,以简化这一步骤,或通过其他方法设置初始用户名。

1 个赞

我同意。那些通用的用户名会让与用户的互动变得更加混乱。由于用户默认只有3天的时间来更新用户名,我预计他们经常会在时间过去之后才注意到,因此工作人员需要负责为他们重命名。
我非常喜欢 Offering blank username suggestions rather than ‘UserN’ at signup 防止了这种情况的发生,例如在这里的meta上。在合并该修复之前,最后一个userXXX是在1月7日创建的。然后在该功能启用之前,没有新的userXXX出现,自那以来已有12个新的userXXX。

4 个赞

此功能非常实用。越来越多的平台采用“通过电子邮件发送一次性验证码”的功能,以提供安全的 MFA 登录体验,而无需用户随身携带特定的设备(装有相应的身份验证器)。

5 个赞

你在创建账户时没有看到这个步骤吗?

这是一条奇怪的引用:看起来像是 DomMcD 引用了我,但事实并非如此。

我并没有测试过这些步骤。我评论的是我在这 Meta 平台上对新用户的一些观察。我在注册时是否看到某个字段并不重要。我需要应对的是其他人如何使用该字段。

我还想知道姓名是如何处理的。虽然并非每个用户似乎都使用系统生成的用户名,但我注意到更多人的名字是 userXXX 这样的格式。

即使更改了用户名,他们似乎也会保留这种格式,结果就是同一个数字被反复使用,直到该用户名被占用,然后才会从下一个数字重新开始。

例如,0102100988082mohamedasarudeenuser603 的名字都是 user603。

我知道他们可以更改名字,但同样,我无法改变与他们互动时的体验。

2 个赞

感谢大家的报告,修复补丁将很快合并:

2 个赞

更新

多亏了 @keegan 最新的工作,我们现在在这一步中拥有了一个用户名生成功能,它会预填一个建议:

一个关于用户体验的小建议,如果可行的话。具体如下:

我的设备相当确定这里需要输入密码,但它应该提示输入电子邮件地址。这样,我的手机等设备就会知道应该提供邮箱地址,而不是其他凭证。

1 个赞