Hi David-- I wanted to just follow up on this thread quickly. After spending a few hours poking around today, I think I finally figured it out-- a way to deliver secure assets (without revealing the asset's underlying permalink) to authorized users.
I wrote up my findings here, if you want to take a look. I achieved it without using any of Firebase's built-in signed-urls or download-urls generators though because from my reading, all those approaches always revealed the assets underlying permalink which I didn't want.
Again, I'm new to Firebase so I'm not positive my approach is 100% full-proof, but I monitored the network tab in Chrome's dev tools console and didn't see any permalinks being unwittingly revealed. So I guess that's at least a start in the right direction. Please let me know if you have any questions or are curious about anything. Firebase is seriously amazing though! It's so good! 🎉🥳
It looks like the same approach as the one I described in my post ("Fetch: Access Image Securely With OAuth2") but, instead of doing the work on the client side, you defer it to a Function. That's a creative and interesting approach 👍.
Nevertheless, regarding the downloadUrl, I am not sure it is "solved". Last time I had a deep look at the question, I figured out that such url are automatically generated by Firebase on each upload, regardless if such a link is called from the client side or not. It might have been a bug but, as long as I remember, it was so. Therefore if you really do not want such link, you would "still" have explicitly ask Firebase to remove it which, as far as I understand, is only possible with GCP but again, I might be wrong and no such link might be automatically generated. It is probably worth a try and look.
First-- yes, regarding the downloadUrl-- I believe you are correct: The moment any file is uploaded to FB Storage, the Google Team, in their infinite wisdom, appears to have decided to by default create a mandatory public url that links to the storage asset. There are ways to bypass this if you're using GCP but with FB, it seems like we don't have a choice. Todd, Frank, David, Doug, et al all strike me as genius-level people so I'm sure there's a legit design decision for this impl. But I have no idea what it is. To me, it just seems like a potential security disaster waiting to happen… automatically creating a "public url backdoor" to any FB storage asset seems… not good? 🤔
(Again, I'm new to FB though so I feel like I honestly must be missing something or am incompletely understanding somewhere. Please lmk if so!)
Second-- so my approach is similar to the one you describe but also different in one significant way (I think). Just so I understand your solution though: In your example, where you specified the endpoint of https://firebasestorage.googleapis.com/.../photo.jpg
and then manually send in the header: 'Authorization': Bearer ${firebase_user_auth_token}
What is ${firebase_user_auth_token} in this example? Are you getting it from here?
I wish I would still be able to have a look to my source code to answer your question regarding firebase_user_auth_token but, as I ditched my concept and went with the dowloaUrl, gonna be hard to find and remember. Honestly don't remember spontaneously, really sorry. Not sure if it is one I fetch with the Firebase SDK or one I define, get and add "manually" as metadata to the assets.
Thanks again for all the feedbacks, really interesting inputs and ideas!
Hi David-- I wanted to just follow up on this thread quickly. After spending a few hours poking around today, I think I finally figured it out-- a way to deliver secure assets (without revealing the asset's underlying permalink) to authorized users.
I wrote up my findings here, if you want to take a look. I achieved it without using any of Firebase's built-in
signed-urlsordownload-urlsgenerators though because from my reading, all those approaches always revealed the assets underlying permalink which I didn't want.Again, I'm new to Firebase so I'm not positive my approach is 100% full-proof, but I monitored the network tab in Chrome's dev tools console and didn't see any permalinks being unwittingly revealed. So I guess that's at least a start in the right direction. Please let me know if you have any questions or are curious about anything. Firebase is seriously amazing though! It's so good! 🎉🥳
Thanks for the follow up Robert 😃.
It looks like the same approach as the one I described in my post ("Fetch: Access Image Securely With OAuth2") but, instead of doing the work on the client side, you defer it to a Function. That's a creative and interesting approach 👍.
Nevertheless, regarding the
downloadUrl, I am not sure it is "solved". Last time I had a deep look at the question, I figured out that such url are automatically generated by Firebase on each upload, regardless if such a link is called from the client side or not. It might have been a bug but, as long as I remember, it was so. Therefore if you really do not want such link, you would "still" have explicitly ask Firebase to remove it which, as far as I understand, is only possible with GCP but again, I might be wrong and no such link might be automatically generated. It is probably worth a try and look.Again thanks for the follow-up, really cool!
Hi David!
So, two quick notes:
First-- yes, regarding the
downloadUrl-- I believe you are correct: The moment any file is uploaded to FB Storage, the Google Team, in their infinite wisdom, appears to have decided to by default create a mandatory public url that links to the storage asset. There are ways to bypass this if you're using GCP but with FB, it seems like we don't have a choice. Todd, Frank, David, Doug, et al all strike me as genius-level people so I'm sure there's a legit design decision for this impl. But I have no idea what it is. To me, it just seems like a potential security disaster waiting to happen… automatically creating a "public url backdoor" to any FB storage asset seems… not good? 🤔(Again, I'm new to FB though so I feel like I honestly must be missing something or am incompletely understanding somewhere. Please lmk if so!)
Second-- so my approach is similar to the one you describe but also different in one significant way (I think). Just so I understand your solution though: In your example, where you specified the endpoint of
https://firebasestorage.googleapis.com/.../photo.jpgand then manually send in the header:
'Authorization': Bearer ${firebase_user_auth_token}What is
${firebase_user_auth_token}in this example? Are you getting it from here?I wish I would still be able to have a look to my source code to answer your question regarding
firebase_user_auth_tokenbut, as I ditched my concept and went with the dowloaUrl, gonna be hard to find and remember. Honestly don't remember spontaneously, really sorry. Not sure if it is one I fetch with the Firebase SDK or one I define, get and add "manually" as metadata to the assets.Thanks again for all the feedbacks, really interesting inputs and ideas!
No worries! 👍 Again, thanks for sharing all of this info on Firebase Storage-- it's super-helpful! Gracias!! 🙏