英文:
Flutter error - [cloud_firestore/permission-denied] The caller does not
问题
我有一个Flutter应用程序,它生成以下错误,显示在应用栏上方:
[cloud_firestore/permission-denied] 调用者没有权限
错误发生时:
1). 当前应用用户从我的应用中注销。
2). 显示登录屏幕
3). 用户使用不同的用户电子邮件/密码登录
错误发生在用户登录之后。
在IDE中没有出现错误日志。
我有以下Firestore规则设置:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents/{collection} {
match /{document=**} {
allow read, write: if request.auth != null
}
}
}
有什么建议吗?
英文:
I have a Flutter app that is generating the following error that is displayed above the app bar
[cloud_firestore/permission-denied] The caller does not have
The error occurs when:
1). The current app user logs out of my app.
2). The login screen is presented
3). The user logs in with a different user email/password
The error occurs AFTER the user has logged in.
No error logs appear in the IDE
I have the following Firestore rule set up
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents/{collection} {
match /{document=**} {
allow read, write: if request.auth != null
}
}
}
Any suggestions?
答案1
得分: 1
Firestore安全规则默认情况下不支持通配符匹配。因此,如果您为特定的document
或collection
指定规则,它不一定会匹配具有相同级别但不同名称的documents
或subcollections
。对于要保护的每个单独的document
或collection
,必须明确定义规则。
如果您希望安全规则递归地应用于collection
或subcollection
中的所有documents
,必须明确为每个级别设置规则。
这是一个安全规则的示例:
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
match /cities/{citiesID} {
allow read: if true;
allow create: if request.auth != null;
allow update, delete: if resource.data.userId == request.auth.uid;
}
// 默认情况下,后备规则拒绝访问。
match /{document=**} {
allow read, write: if false;
}
}
}
您可以参考关于在Cloud Firestore Security Rules中编写规则的文档以及Structuring Cloud Firestore Security Rules。
您还可以查看这个Stackoverflow上的答案,这可能会对您有所帮助。
英文:
Firestore security rules are not wildcard-matched by default. Accordingly, if you specify a rule for a certain document
or collection
, it wont necessarily match documents
or subcollections
with the same level but different names. For any single document
or collection
you want to safeguard, rules must be explicitly defined.
You must specifically set rules for each level if you want security rules to be applied recursively to all documents
in a collection
or subcollection
.
Here is an example of a Security Rule:
service cloud.firestore {
match /databases/{database}/documents {
collections
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
match /cities/{citiesID} {
allow read: if true;
allow create: if request.auth != null;
allow update, delete: if resource.data.userId == request.auth.uid;
}
// By default, the fallback rule denies access.
match /{document=**} {
allow read, write: if false;
}
}
}
You may refer to this documentation about Writing Rules in Cloud Firestore Security Rules and Structuring Cloud Firestore Security Rules.
You may also check this Stackoverflow answers that might help you.
答案2
得分: 0
已解决。
问题出在一个调用Firebase流的RiverPod StreamProvider上,而RiverPod提供程序缺少了'autodispose'后缀。
没有'autodispose'后缀,旧用户凭据的Firebase流会保持活动状态,而应用于新用户。
英文:
Resolved.
The problem was a RiverPod StreamProvider that was calling a Firebase stream, and the RiverPod provider was missing the 'autodispose' suffix.
Without the 'autodispose' suffix the Firebase stream with the old user credentials was kept alive for the new user.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论