I have been playing around with firestore and the security rules feature. These are my current rules -

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /categories/{category} {
      allow read: if request.auth != null && request.auth.uid == resource.data.uid;
      allow write: if request.auth.uid == request.resource.data.uid;
    }
    match /expenses/{expense} {
      allow read, write;
    }
  }
}

When my client side application creates a new document the request looks like this -

{
  uid: "someUID",
  name: "Food"
}

I was playing around and testing these rules and noticed that when I don't supply uid in the request then I get an error - Property uid is undefined on object. My question is, is this considered good practice? Should I let the rule try to access the uid property without knowing it exists? Or is there a way to validate custom data types? Perhaps somethig like this -

allow write: request.resource.data.uid != null && request.auth.uid == request.resource.data.uid;

CodePudding user response：

An error like that just terminates the evaluation of the expression and rejects access. There are no harmful side-effects. If you're fine with that error resulting in the immediate rejection of access, then it's OK. There would be no advantage to adding additional checks that continue to reject access in the same situation. In fact, you are just using up your available space for rules that don't add any clear value other than your own satisfaction.