Handling of 'reference' field type in Firestore - currently it exposes sensitive information and is unintuitively formatted

[alexobviously]

Hi, I posted this on the Algolia forum: https://discourse.algolia.com/t/how-to-handle-firestore-reference-types-in-algolia-currently-they-store-sensitive-and-unnecessary-information-when-imported/12685

But after having reviewed the code of this tool, I think it's more appropriate to open an issue here.

Quick summary:

• It seems that the format returned when fetching a Reference field value from Firestore is a JSON object with a bunch of extraneous data (rather than, e.g. just a string with the path or an array of the path segments)
• Included in that data is a _firestore.settings.credentials sub-field that includes a private SSH key!
• Because we are retrieving the data with the admin SDK, this SSH key has admin privileges
• Apart from the security issue, there's a load of useless information that inflates the size of records, and the format in general makes handling the field in Algolia pretty complicated

So after looking at the code, it looks like there's no processing at all happening on the extracted data, and it seems like it would be relatively straightforward to implement something. Like if(value.dataType == DocumentReference) payload[field] = value._path.segments; - I don't know the exact syntax or field names off the top of my head but something like that should work I think.

I don't mind implementing this but maybe someone from Algolia should specify what the desired behaviour is (should it preserve any of the random non-private information? should it be an array like segments right now or just a string (i.e. segments.join('/'))?

[smomin]

hey @alexobviously I am looking at this right now. I hope to get this out by this week. I will attach the PR number to this issue once it is released. Let me know if you have any questions.

[smomin]

PR #30: Support for Timestamp, Reference, and GeoPoint field type processing.

[alexobviously]

Seems to be working well for us, thanks @smomin!