Firebase：为安全用户创建匿名用户是最好的做法，即使应用程序不否则对用户信息做任何事情？
我有一个公共网络应用程序，对用户/身份验证没有应用程序的需求，但是确实依赖Firebase后端功能，例如云功能和Firestore。
鉴于这一点，创建匿名用户仍然是最好的做法吗？我很难看到好处。如果我创建了匿名用户，我可以限制他们的调用，但这似乎很容易到达，我宁愿不限制普通用户，同时仍然为邪恶的人打开大门。
在确实需要用户，注册，付款等的应用程序中，我通常会以之类的功能启动功能，如果（context.auth.auth＆amp;＆amp; auth.auth.user.issubscribed）{//运行App logic} < /code>，没有那个感觉有点赤裸了 - 但是如果不是安全性，我很高兴跳过。
我最底线的关注是，如果我有真正的公共云功能，那是突然的，巨大的成本，但这也许是没有根据的。
I have a public web app that has no app-logical need for users/authentication, but that does rely on Firebase back-end features, such as cloud functions and Firestore.
Given that, is it still best practice to create anonymous users? I'm having a hard time seeing the benefit. If I created anonymous users, I could restrict their invocations, but that seems pretty easy to get around, and I'd rather not restrict the average user while still leaving the door open for someone nefarious.
In apps that do require users, sign-up, payments, etc, I usually start functions with something like if (context.auth && context.auth.user.isSubscribed) { // run app logic } and it feels a bit naked to be without that -- but I'd be delighted to skip that if it's not a security gaffe.
My bottom-line concern is about sudden, massive costs if I have a truly public cloud function, but maybe that's unfounded.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用匿名身份验证将数据持续关联，而无需对该用户有任何可识别的知识。因此，一个典型的示例是允许用户在登录购物车之前将某些东西放入购物车中。使用匿名身份验证使您可以将购物车与用户关联并安全访问它，而无需用户输入凭据。
如果您不需要将数据与用户关联，则通常没有理由匿名签名。
只需匿名签署用户是（与半知名信念相反）不是安全措施。正如您已经说过的：任何人都可以致电API登录，因此仅要求某些人签名并不会阻止太多滥用。
但是，在您的示例中，
context.auth.user.issubscribed>但是，用户还需要具有issubScribed索赔。这种索赔通常只能由可以访问您的项目管理凭证的人设置，因此，这种检查是是一个有用的安全措施。实际上，这就是我一开始所说的，这是您想要与用户相关联的数据。Use anonymous authentication to persistently associate data with the user, without having any identifiable knowledge about that user. So a typical example is to allow the user to put something in the shopping cart before they sign in. Using anonymous authentication allows you to associate the cart with the user and secure access to it, without requiring the user to enter credentials.
If you have no need to associate data with the user, there typically is not reason to sign them in anonymously.
Just signing the user in anonymously is (contrary to semi-popular belief) not a security measure. As you already said: anyone can call the API to sign in, so just requiring that some is signed in doesn't deter much abuse.
In your example of
context.auth.user.isSubscribedhowever, the user also needs to have anisSubscribedclaim. This sort of claim can typically only be set by somebody who has access to your projects administrative credentials, so that sort of check is a useful security measure. And in fact, it's what I said at the start, a piece of data that you persistently want to associate with the user.