使用Firebase Auth在NextJS中实现用户角色。

huangapple go评论179阅读模式
英文:

Implement user roles with Firebase Auth (NextJS)

问题

我正在尝试为我的网站(一种博客类型)创建多层次角色系统。

我已经实现了经典的Firebase Auth身份验证系统,仅使用电子邮件/密码组合。到目前为止,每个用户都可以发布/编辑文章,因为我没有任何细分。我想改变这一点,并在几个角色之间建立分离 - 首先是管理员/版主/用户,但是角色似乎不是默认的Firebase用户模型可用。

我如何可能迁移我的逻辑到这里,并且不必重新做一切?我看到有人使用Firestore(但这是很久以前的事情,Firebase肯定已经改变了),还有一些人倾向于使用Firebase Auth SDK。到目前为止,使用这个Identity Platform的新功能也是可用的,我还不太了解。

请注意,我正在使用:

  • NextJS 13(仅JavaScript)与集成的Next API(SSR)
  • 部署在Vercel上
  • 数据库分为一些Firebase存储资源(主要是图像)和MongoDB(其他一切)
英文:

I'm trying to create a multi-level role system for my website (which is a type of blog).

I've already implemented classic Firebase Auth authentication system, with email/password combo only. By now, every user can post/edit articles because I do't have any granularity. I'd like to change that and make a separation between several roles - starting by Admins/Moderators/Users, but roles don't seem to be available as the default Firebase User model.

How can I possibly migrate my logic to this, and which tool should I use withotu having to redo everything? I've seen people using Firestore (but this was a long time ago, Firebase must've changed since then), and some others tend to prefer the Firebase Auth SDK. By now, new things are even available with this Identity Platform thing, which I don't really understand yet.

Note that I'm using:

  • NextJS 13 (Javascript only) with integrated Next API (SSR)
  • Deployment on Vercel
  • Database split between some Firebase Storage assets (mostly images) and MongoDB (everything else)

答案1

得分: 2

你可以创建自己的用户表或集合,其中存储用户的角色与电子邮件或用户ID相关联。

英文:

You can create your own user table or collection which holds user's role against the email or userId.

答案2

得分: 2

Firebase Authentication仅处理身份验证(验证用户的身份),它没有内置的授权机制(确定用户被允许执行什么操作)。

也就是说,您可以在Firebase之上构建多种授权模型的方式。一些需要考虑的主题包括:

  • 存储授权信息(在您的用例中的角色)的两个常见位置:要么作为用户资料中的自定义声明,要么作为数据库中的单独记录。

  • 要保护对Cloud Storage中文件的访问,您可以使用Firebase安全规则。有关示例,请参阅Firebase文档中有关实施自定义声明属性和角色的部分。以下是需要注意的几点:

    • 安全规则适用于通过Firebase客户端端SDK访问Cloud Storage的访问,但不适用于通过下载URL或Google Cloud(服务器端)SDK访问文件的情况。
    • 示例显示了用户的角色存储为其用户资料中的自定义声明。尽管这在今天仍然是可能的,但您现在还可以从Storage安全规则中访问Firestore,从而提供了另一种存储用户角色信息的选项。
  • 对于MongoDB,您将需要在自己的代码中实现授权。如果您将授权信息存储为用户资料中的自定义声明,您可以解码令牌并从中获取信息。如果将其存储在数据库中,则可以从那里读取并应用它。

英文:

Firebase Authentication only handles authentication (validating the user's identity). It does not have any built-in mechanism for authorization (determining what the user is allowed to do).

That said, you can build an authorization model on top of Firebase in a multitude of ways. Some topics to consider:

  • There are two common places to store the authorization information (the roles in your use-case): either as a custom claim in the user's profile, or as separate records in a database.

  • For securing access to the files in Cloud Storage, you can use Firebase security rules. For an example of this, see the Firebase documentation on implementing custom-claim attributes and roles. A few things to note here:

    • Security rules are applied to access to Cloud Storage through the Firebase client-side SDKs, but not when you access the file through a download URL or through a Google Cloud (server-side) SDKs.
    • The example shows the user's role being stored as a custom claim in their user profile. While this is still possible today, you can nowadays also access Firestore from Storage security rules which gives you a second option on where to store the user's role information.
  • For MongoDB, you will have to implement authorization within your own code. If you stored the authorization information as custom claims in the user profile, you can decode the token and get the information from there. If you stored it in a database, you can read it from there and apply it.

huangapple
  • 本文由 发表于 2023年7月23日 21:16:59
  • 转载请务必保留本文链接:https://go.coder-hub.com/76748441.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定