В правилах безопасности пожарного депо мы должны избегать ошибок, или это так же, как запретить

Question

В моих правилах безопасности мне нужно иметь определенное свойство в некоторых объектах.

Например, когда пользователь публикует что-то, что может изменить только он сам, поэтому в подколлекции /posts/ каждое сообщение имеет по крайней мере идентификаторвладельца.

Например,

{
   owner: 'idOwner-xxxxxx'
}

, поэтому в этом примере я установил свои правила безопасности как таковые

service cloud.firestore 
{
  match /databases/{database}/documents 
  {
    match /posts/{postId} 
    {
      allow read;

      allow create: if request.resource.data.owner == request.auth.uid;

      allow update: if request.resource.data.owner == request.auth.uid
      && resource.data.owner == request.auth.uid;

      allow delete: if resource.data.owner == request.auth.uid;
    }
  }
}

Так просто пользователю нужно загрузить сообщениес его собственным идентификатором и имеет контроль над ним только в том случае, если его идентификатор находится в нем.

Но на симуляторе, если я пытаюсь загрузить объект без ключа ключа, пример:

{
  notOwnerKey: 'qwertz'
}

из-за отказа в разрешении я получаю ошибку

Error: simulator.rules line [x], column [x]. Property owner is undefined on object.

Я могу избежать ошибки, сначала проверив ключ:

service cloud.firestore 
{
  match /databases/{database}/documents 
  {
    match /posts/{postId} 
    {
      allow read;

      allow create: if "owner" in request.resource.data
      && request.resource.data.owner == request.auth.uid;

      allow update: if "owner" in request.resource.data
      && request.resource.data.owner == request.auth.uid;
      && "owner" in resource.data
      && resource.data.owner == request.auth.uid;

      allow delete: if "owner" in resource.data
      && resource.data.owner == request.auth.uid;
    }
  }
}

При этом я не получаю ошибку, кромекод в два раза длиннее и будет болезненным для вложенного объекта.

Итак, вот мой вопрос.

Есть ли различия между ошибками и отказом в разрешении с точки зрения производительности и передовой практики?

Должны ли мы избежать ошибки?

Answer 1

Ошибки по сути такие же, как отрицать. Вам не нужно усложнять свои правила, чтобы избежать их, вы можете просто использовать их как неявное отрицание.