【问题标题】:How to join application data with Cognito User Pool + Cognito Identity Pool users?如何将应用程序数据加入 Cognito 用户池 + Cognito 身份池用户?
【发布时间】:2016-11-10 00:17:37
【问题描述】:

如果我有一个 Cognito 用户池和一个 Cognito 身份池,并且我有特定于应用程序的数据,那么在如何将它们结合在一起方面是否有任何被认为是最佳实践的方法?

例如,假设我将应用程序数据存储在 DynamoDB 中,可能是用户发送的 SMS/文本消息。还假设一条短信(存储在数据库中)如下所示:

{
    "account_id": "a-uuid-for-the-account",
    "message_body": "Hello world",
    "message_subject": "Greetings!",
    "date_sent": "...",
    "message_id": "..."
}

然后我会将其加入用户池还是身份池?例如,一个单独的帐户表可能有类似这样的记录:

{
    "account_id": "a-uuid-for-the-account",
    "user_pool_username": "MrBloggs"
    "addresses": [ "123 Springfield Road", "Blahsville" ]
}

我可以看到加入用户池的缺点,因为您可能会引入其他 IDP,然后这会失败。那么也许,您会使用身份池“身份”的 ID?

最后,这个问题让我想知道您可能针对用户池用户(在用户池本身中)存储的“属性”有什么意义?以上面使用的邮政地址为例,如果它存储在用户池中,那么您必须单独为其他 IDP 中的用户存储地址——重复工作并使软件复杂化。

谢谢!

【问题讨论】:

    标签: amazon-web-services amazon-cognito


    【解决方案1】:

    一种选择是使用 Cognito 用户池作为您的 Cognito 身份池的提供者,然后它会为您提供访问 Dynamo 的凭据。

    如果您使用多个提供商,最有意义的方法可能是使用 Cognito 身份池生成的 id(身份 id)作为 Dynamo 中的密钥,因为用户可能只能使用某些公共提供商登录,而不是用户池。

    一旦登录链接,此身份 ID 将保持不变,但有一个例外。如果两个经过身份验证的身份合并到一个身份池中,则生成的身份 id 可能是其中之一。由于 Dynamo 以它的方式工作,这意味着您必须捕获合并事件,然后从 Dynamo 中获取旧密钥存在的所有条目,删除它们,然后用新密钥重新插入它们。诚然,这不是最顺利的场景,我们将把它作为一个功能请求来简化这个用例。

    针对用户存储数据的设计并没有真正考虑到 Cognito 联合身份(身份池),仅考虑用户池。当用户池更像是一个独立的实体时,它确实最有意义,而不是在您描述的用例中那么多。

    【讨论】:

    • Cognito 身份池生成的 id(身份 id)是否可以用作 DynamoDB 表中的主键?这是推荐的行为吗?
    • 只有在身份合并的情况下,经过身份验证的 ID 的身份 ID 才会更改。如果身份 a 具有用户池身份验证并且身份 b 具有 facebook,假设您将身份 a 的用户池令牌和身份 b 的 facebook 令牌与身份 a - 这将触发合并。生成的身份 id 可以是 a 或 b,它是随机的。
    • 所以,如果你可能合并,它可能会改变,否则不会。如果您使用的是用户池,则子字段是该用户的唯一标识符,也可以使用。
    猜你喜欢
    • 2020-04-21
    • 2017-02-28
    • 2018-02-11
    • 1970-01-01
    • 2018-07-17
    • 2016-09-26
    • 2016-10-23
    • 2019-04-01
    • 1970-01-01
    相关资源
    最近更新 更多