因此，我试图了解 AWS Cognito，但我遇到了一些问题。
所以，现在我可以注册一个帐户，验证并登录。很简单。边缘案例是我的墙壁所在的地方。
这是我到目前为止的信息：
username的一旦创建就不能更改- 我使用 UUID 作为我的
username值 email被标记为别名，在 Cognito 术语中意味着我可以使用它来登录username。如果
email被选为别名，根据文档，相同的值不能用作用户名（http://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user -池设置别名）：如果选择电子邮件作为别名，则用户名无法匹配有效的电子邮件格式。同样，如果选择电话号码作为别名，则该用户池的服务将不接受与有效电话号码模式匹配的用户名。
该
email地址只能在帐户经过验证后用于登录（http://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-别名）只有在电话号码和电子邮件地址经过验证后，电话号码和电子邮件地址才会成为用户的活动别名。因此，如果您选择将电子邮件地址和电话号码用作别名，我们建议您选择自动验证它们。
这是我的边缘案例。
如果用户注册但未立即验证：
- 他们被叫走
- 也许应用程序崩溃
- 他们失去了连接
- 他们的电池没电了
- 他们强制退出
- 应用程序被意外删除。
在他们看来，他们已经注册只是没有验证他们的帐户。在这一点上，它实际上无法验证他们认为他们注册的帐户。我想这可以通过消息传递来解决：
“警告在您验证您的电子邮件地址之前，不会创建您的帐户。” 或类似的规定。反正...
- 他们无法尝试登录，因为他们不知道随机分配为他们的
username. - 即使不是这样，他们也提供了他们的电子邮件地址作为他们的用户名。从用户的 POV 来看，他们甚至不知道他们
username可能是什么，因为他们只输入了他们的电子邮件地址。 - 他们所能期望的最好的结果就是尝试再次注册。（假设他们阅读了上面的验证警告）在这种情况下，现在 Cognito 可能已经放弃了未经确认的账户堆积。
“堆积”可能是一个过于强烈的短语，这可能是一个非常边缘的案例。
现在有利的一面是，由于他们还没有“验证”他们可以使用相同的地址email再次注册，因为直到. 如果有人试图验证一个已经验证过的地址，他们会得到一个. 这实际上提出了一个有趣的观点，我也刚刚测试过。emailemailverifiedAliasExistsException
我可以使用电子邮件地址注册，然后验证该电子邮件地址，以便帐户得到确认。然后我可以右转并使用相同的电子邮件地址注册，并且在尝试使用重复的电子邮件地址验证该帐户之前，我不会收到官方的 AWS 错误。没有任何方法可以更早地显示此错误吗？我猜期望是开发人员在 Pre-Signup Trigger 中编写验证服务：
当用户提交他们的信息进行注册时调用此触发器，允许您执行自定义验证以接受或拒绝注册请求。
总结一下，重申一下这个问题：
实际上，似乎需要在 Cognito 中使用电子邮件地址时，需要预先注册 Lambda 以确保不存在带有电子邮件的帐户，因为在验证尝试之前不会处理 AWS 异常制成。
我的假设在这里正确吗？通过这里的要求，我认为尽快让用户知道电子邮件地址不可用是非常合理的。例如：
John Doe : jdoe@gmail.com
Jane Doe : jdoe@gmail.com