I'm working on my first site built with firebase, and a little intimidated by the "serverless" architecture. I'm used to doing a lot of backend verification, and having the client decide too many things is making me want to be very defensive.
One such example is this. Users can submit posts. Posts can contain files. Each of those in isolation is manageable
firestore().collection('posts').add({
title: "my new post",
author: "my username",
uploaded: new Date(),
location: "a10b308cd" // some location in firebase storage
});
I can use firestore rules to make sure the author matches the authenticated user, and stuff like that.
Likewise I can upload a file:
const uuid = new UUID();
const ref = firebase.storage().ref().child(uuid);
ref.put(file)
But it's very confusing to me how I should link these two together. The solution seems to be that the client comes up with a UUID for the storage location (namespaced to the user even) - and uses that in both the firestore.add() and the ref.put() calls.
There just doesn't seem a ton I can do to validate this behavior is correct though. I'm not used to having to trust clients to place files in the right places in my backend. It's unlikely there's going to be lots of malicious clients making messed up links, but it's still very unsettling to me.
Not even a malicious scenario, but if my Storage didn't submit (EG because of internet issues or incorrect file upload against Storage rules) and the client still tried to make a document addition, I'd have no way in firestore.rules to if they'res a file where they are linking.
I have a regex to determine if the uuid looks like a uuid, but clients could still set it to "deadbeef1010101010" and I'm powerless to stop it! A randomly generated backend UUID is much preferable than relying on clients - even though it shouldn't matter when they're namespaced.
Am I thinking about this all wrong?