Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.6k views
in Technique[技术] by (71.8m points)

firebase - Firestore Security Rules - How can I check that a field is/isn't being modified?

For the life of me, I cannot understand why the following is resulting in a false for allowing writes. Assume my users collection is empty to start, and I am writing a document of the following form from my Angular frontend:

{
  displayName: 'FooBar',
  email: 'foo.bar@example.com'
}

My current security rules:

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      function isAdmin() {
        return resource.data.role == 'ADMIN';
      }

      function isEditingRole() {
        return request.resource.data.role != null;
      }

      function isEditingOwnRole() {
        return isOwnDocument() && isEditingRole();
      }

      function isOwnDocument() {
        return request.auth.uid == userId;
      }

      allow read: if isOwnDocument() || isAdmin();
      allow write: if !isEditingOwnRole() && (isOwnDocument() || isAdmin());
    }
  }
}

In general, I want no users to be able to edit their own role. Regular users can edit their own document otherwise, and admins can edit anyone's.

Stubbing isEditingRole() for false gives the expected result, so I've narrowed it down to that expression.

The write keeps coming back false, and I cannot determine why. Any ideas or fixes would be helpful!

Edit 1

Things I've tried:

function isEditingRole() {
  return request.resource.data.keys().hasAny(['role']);
}

and

function isEditingRole() {
  return 'role' in request.resource.data;
}

and

function isEditingRole() {
  return 'role' in request.resource.data.keys();
}

Edit 2

Note that eventually, admins will set a role for users, so a role could eventually exist on a document. This means that, according to the Firestore docs below, the request will have a role key, even if wasn't in the original request.

Fields not provided in the request which exist in the resource are added to request.resource.data. Rules can test whether a field is modified by comparing request.resource.data.foo to resource.data.foo knowing that every field in the resource will also be present in request.resource even if it was not submitted in the write request.

According to that, I think the three options from "Edit 1" are ruled out. I did try the suggestion of request.resource.data.role != resource.data.role and that's not working either... I'm at a loss and am beginning to wonder if there's actually a bug in Firestore.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)
Waitting for answers

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...