Cognito auth流程失败,"已找到用户名Facebook_10155611263153532的条目"

Bir*_*sky 11 amazon-web-services oauth-2.0 amazon-cognito amazon-cognito-facebook

目标是实现社交提供程序身份验证流程,如用户池应用程序集成和联合中所述.

我想要满足的一个重要事项是合并具有相同电子邮件地址的用户池帐户.

我通过在PreSignUp_ExternalProvider cognito lambda触发器中调用adminLinkProviderForUser来实现这一点.

因此,一切正常.新社交提供的用户正在注册并与现有的Cognito(用户+密码)用户链接.

但是,从用户的角度来看,身份验证流程尚未完成.它在调用回调uri(在cognito用户池中定义)的最后一步失败:

错误:invalid_request

error_description:已找到用户名Facebook_10155611263152353的条目

但是,如果用户重试社交身份验证流程,则一切正常,并且会获得代表原始Cognito用户池用户(已经拥有该电子邮件的用户)的会话令牌.

请注意,我正在测试空用户池上的auth流,零用户帐户.

小智 21

对于所有仍在 2020 年与此问题作斗争的可怜人,就像我所做的那样:

  • 我最终通过在我的客户端应用程序中捕获“已找到用户名条目”并再次重复整个身份验证流程来解决该问题。
  • 幸运的是,该错误仅在初始外部提供商注册时触发,而不会在同一用户的后续登录中触发(因为它发生在注册触发器期间,呃)。我在胡乱猜测,但这是我认为正在发生的事情:
    • 就我而言,facebook 提供商成功地与预先存在的 cognito 电子邮件/密码用户建立了联系。已成功创建链接到电子邮件/密码用户的新 Facebook 用户池条目。
    • 尽管如此,cognito 似乎试图在内部注册过程中注册完全隔离的 Facebook_id 用户(即使在上一步中已经创建了具有相同用户名的链接用户条目)。由于用户名 Facebook_id 的“链接用户”已经存在,因此 Cognito 抛出了“已经找到用户名 Facebook_id 错误的条目”内部错误。
    • 自 2017 年以来,这个错误一直在向 AWS 开发人员反映,甚至有一些他们正在处理它,但到 2020 年,它仍然没有修复。

  • 面临同样的问题,甚至不确定 cognito 是否值得使用。这项服务浪费的时间比节省的时间还要多。失望的。真的很失望。 (7认同)

age*_*420 5

是的,这就是当前的设置方式。如果您尝试使用 PreSignUp 触发器链接用户,第一次将不起作用。处理此问题的更好方法(我认为)是在用户界面中提供一个选项,用于在登录时链接外部帐户。在预注册触发器中,搜索具有相同唯一属性(例如电子邮件)的用户,并查看注册是否来自外部提供商。然后显示一条消息,例如电子邮件已存在。登录并使用此菜单/选项进行链接。不过还没有测试过。

  • 这是一个糟糕的用户体验。如果用户使用不同的提供商登录(也许他们忘记了最初使用的是哪一个),它应该透明地自动链接。 (8认同)