5

The simulator now displays an error message trying to access request.writeFields.
Before that writeFields in Firestore Security Rules did just not work in real requests.

The message states the following:

The simulator only simulates client SDK calls; request.writeFields is always null for these simulations

Does this mean that writeFields are only specified in HTTP requests?

The documentation only states this:

writeFields: List of fields being written in a write request.

A problem that arises from this

I am searching for something that replaces this property because it is "always null".
request.resource.data in update also contains fields that are not in the requests, but already in the document to my knowledge.

Example

// Existing document:

  document:
    - name: "Peter"
    - age: 52
    - profession: "Baker"

// Update call:

  document:
    - age: 53

// request.resource.data in allow update contains the following:

  document:
    - name: "Peter"
    - age: 53
    - profession: "Baker"

But I only want age.

Community
  • 1
  • 1
creativecreatorormaybenot
  • 114,516
  • 58
  • 291
  • 402

1 Answers1

14

EDIT Mar 4, 2020: Map.diff() replaces writeFields functionality

The Map.diff() function gives the difference between two maps: https://firebase.google.com/docs/reference/rules/rules.Map#diff

To use it in rules:

// Returns a MapDiff object
map1.diff(map2)

A MapDiff object has the following methods

addedKeys() // a set of strings of keys that are in after but not before
removedKeys() // a set of strings of keys that are in before but not after
changedKeys() // a set of strings of keys that are in both maps but have different values 
affectedKeys() // a set of strings that's the union of addedKeys() + removedKeys() + updatedKeys()
unchangedKeys() // a set of strings of keys that are in both maps and have the same value in both

For example:

// This rule only allows updates where "a" is the only field affected
request.resource.data.diff(resource.data).affectedKeys().hasOnly(["a"])

EDIT Oct 4, 2018: writeFields is no longer supported by Firestore and its functionality will eventually be removed.

writeFields is still valid, as you can see from the linked documentation. What the error message in the simulator is telling you is that it's unable to simulate writeFields, as it only works with requests coming from client SDKs. The simulator itself seems to be incapable of simulating requests exactly as required in order for writeFields to be tested. So, if you write rules that use writeFields, you'll have to test them by using a client SDK to perform the read or write that would trigger the rule.

Sam Stern
  • 24,624
  • 13
  • 93
  • 124
Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • Are you saying that the stress in that error message is on "**simulates**"? I will need to do a lot more testing in that case because `writeFields` do not seem to be working for me as I described in my older question, which is linked at the beginning of this question. – creativecreatorormaybenot Sep 05 '18 at 20:05
  • Yes, if you want to validate your rules that work with writeFields, you'll need to do that with client code for now. – Doug Stevenson Sep 05 '18 at 20:07
  • @DougStevenson the link to `writeFields` documentation doesn't mention anything about writeFields. Where can we find the docs for this? – abagshaw Oct 03 '18 at 04:51
  • @abagshaw writeFields was recently removed from the documentation, as it's being deprecated, and sometimes it doesn't work that way you'd expect. As of now, you should work without it. – Doug Stevenson Oct 04 '18 at 19:45
  • @DougStevenson is there some sort of workaround for issues like https://stackoverflow.com/questions/49671227/allow-update-on-single-field-in-firestore that relied on writeFields? – abagshaw Oct 04 '18 at 19:56
  • @DougStevenson Is there any alternative to writeFields then? Or planned.. – DarkNeuron May 29 '19 at 08:42
  • I can answer my own question with this: https://groups.google.com/forum/#!topic/firebase-talk/5NzKaYF4JYg Long story short: Yes something is, by the sound of it, almost ready. – DarkNeuron Oct 09 '19 at 08:58
  • perfect answer! – coolcool1994 Mar 30 '20 at 20:29