【问题标题】:Custom claims vs accessing refs in security rules?自定义声明与访问安全规则中的引用?
【发布时间】:2017-12-05 12:46:36
【问题描述】:

我们正在将 Firebase 应用与 Twitter auth 集成,并使用 Twitter screen_name 作为我们在数据库中任何地方的主要人类可读用户名。

当涉及到安全规则时,这显然是一个缺点:我们不知道screen_name,因为它不包含在auth.token 中。我们能做的,是root.child('users').child($screen_name).child('uid').val() === auth.uid

让 Twitter screen_name 进入 auth.token 安全规则上下文的唯一方法是通过自定义声明,对吗?这样做的首选方法是什么?其他人类可读用户名的模式建议?

【问题讨论】:

    标签: firebase firebase-authentication firebase-security


    【解决方案1】:

    add custom claims to user tokens 选项是 Firebase 身份验证的一个相对较新的附加功能。在此功能可用之前,在数据库中存储附加信息是完成许多场景的唯一方法。因此,您会发现大多数示例、问题和文档都展示了如何在数据库中存储附加信息。

    不过,在令牌中存储额外的声明有很多优点。其中一些:

    • 自定义声明已在您的安全规则中可用,而从数据库中读取信息通常需要额外读取。
    • 自定义声明在所有产品的安全规则中都可用,而从数据库中读取附加信息仅适用于数据库规则。

    使用数据库存储附加信息还有几个优点:

    • 数据库中的信息可以相对不受限制,而自定义索赔信息必须非常简短。
    • 我通常更喜欢查看数据库中的附加信息,因为这样更容易扫描信息。

    如果您在安全规则中使用 Twitter 屏幕名称,这听起来很适合自定义声明。如果您还想在 UI 中为用户显示 Twitter 屏幕名称,您可能想将其存储在数据库中。

    【讨论】:

    • 整洁!我阅读了自定义声明,我们将使用该选项:我们已经为auth.onCreate 提供了一个功能,只需在此处添加screen_name。应该在第一次登录时立即可用,对吧?当然,我们还会跟踪screen_name 以使数据库本身更具可读性。这更像是对我们的开发人员的让步。谢谢,弗兰克!
    • 另外,您说:自定义声明在所有产品的安全规则中都可用。您的意思是跨 Firebase 产品,例如Firestore?
    • 是的。声明在实时数据库、Cloud Storage for Firebase 和 Cloud Firestore 的安全规则中可用。
    • @FrankvanPuffelen 在哪里可以找到如何添加自定义声明的示例?
    • 好问题。见firebase.google.com/docs/auth/admin/custom-claims。我还在我的答案中添加了链接。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-10-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多