因此，我试图了解AWS Cognito，但我遇到了一些问题 .
所以，现在我可以注册一个帐户，并验证并登录 . 简单就够了 . 边缘的情况是我的墙壁 .
这是我到目前为止的信息：
-
username一旦创建就无法更改 -
我使用UUID作为我的
username值 -
email被标记为 alias ，在Cognito术语中表示除了username之外我还可以使用它来登录 . -
如果选择
email作为 alias ，则根据文档，相同的值不能用作用户名（http://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases）：
如果选择电子邮件作为别名，则用户名与有效的电子邮件格式不匹配 . 同样，如果选择电话号码作为别名，则该用户池的服务将不接受与有效电话号码模式匹配的用户名 .
email地址可以 ONLY 用于在帐户 verified （http://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases）后登录
电话号码和电子邮件地址仅在验证电话号码和电子邮件地址后才成为用户的活动别名 . 因此，如果您选择将它们用作别名，我们建议您选择自动验证电子邮件地址和电话号码 .
这就是我的优势所在 .
如果用户注册，但 NOT 立即验证：
-
他们被叫走了
-
也许应用程序崩溃了
-
他们失去了连接
-
他们的电池坏了
-
他们强行退出
-
app被意外删除了 .
在他们看来，他们已注册但未验证他们的帐户 . 在这一点上，它实际上没有办法验证他们认为他们注册的帐户 . 我猜它可以通过消息解决：
“在您验证电子邮件地址之前，警告您的帐户不会被创建 . ”或类似的规定 . 无论如何...
-
他们可以't attempt to sign in as they won'知道随机分配为
username的UUID . -
即使那不是't the case, they provided their email address as their username. From the user'的POV，他们也不知道他们的_511042甚至可能是什么，因为他们只输入了他们的电子邮件地址 .
-
他们最希望的是尝试再次注册 . （假设他们阅读了上面的验证警告）在这种情况下，现在Cognito可能已经放弃了堆积的 unconfirmed 帐户 .
“堆积”可能是一个过于强烈的短语，这可能是一个非常边缘的情况 .
现在好的方面是，因为他们没有"verified"他们 email 他们可以使用相同的 email 地址再次注册，因为 email 不't get uniquely constrained until it' s verified . 如果有人试图验证已经验证过的地址，则会收到 AliasExistsException . 这实际上提出了一个我刚刚测试过的有趣点 .
我可以使用电子邮件地址注册，然后验证该电子邮件地址，以便帐户得到确认 . 然后，我可以向右转并使用 same 电子邮件地址注册，但我之前没有任何方式来表达此错误？我想期望开发人员在预注册触发器中编写验证服务：
当用户提交其注册信息时，将调用此触发器，允许您执行自定义验证以接受或拒绝注册请求 .
总结一下，并重申一下这个问题：
实际上，似乎是 required ，当使用带有Cognito的电子邮件地址时，需要预先注册Lambda，以确保在进行验证之前不会处理带有电子邮件的帐户 .
我的假设在这里是否正确？通过 required 这里我认为让用户知道电子邮件地址不能尽快提供是非常合理的 . 例如：
John Doe : jdoe@gmail.com
Jane Doe : jdoe@gmail.com