I have a situation where I'm trying to enable Firebase Storage but also have an App Engine deployment which already created the buckets {project_name}.appspot.com and it give me the following error message:
I'm aware you can change the Firebase bucket after enabling Firebase Storage from the Firebase console, however I don't see a way to do it before/while enabling Firebase Storage.
I'm working with a few restrictions and want to see if I can enable Firebase storage with those. My first restriction is that I cannot create a separate GCP project for this. We have billing credits which are linked to the project. Another is that I cannot change the App Engine configuration, or rather doing so will only be done in the worst case since that's already being used for a production workload. Lastly, our parent organization is pretty strict in terms of their Org policies and is likely not willing to change it.
Is there a way specify a different bucket to enable Firebase Storage to avoid the conflict?
I created a GCP project with an App Engine app and a Firebase project with Firebase Storage enabled. According to the documentation these services require a default resource location in order to be initially provisioned. Firebase Storage makes use of the same default bucket as App Engine to initialize. It appears that your organization might have blocked access to this bucket, which makes Firebase Storage not to work initially. You should request the organizational policies to be temporarily allowed while Firebase Storage is provisioned, and then, as you mentioned, you can change the bucket used by Firebase Storage to a different one. Firebase makes use also of the following Storage service account:
You should make sure that this account has permissions to perform its operation at creation time of the bucket, from the FAQ it also explains this is needed:
Cloud Storage for Firebase creates a default bucket in the App Engine free tier.
Related
I want to create a Udemy like video platform where a user can see all videos but can watch videos only that he has purchased.
I am making a rest call to get the videos from the storage bucket from an angular application, using Firebase authentication here. In my GET request to storage bucket I am passing the access token that I got from Firebase authn.
Does this access token can be used to determine scope of the user to access video in a bucket?
Assume if I have given read access for a video in a bucket for a specific user, using the access token can I get the video? But every time I tried it shows unauthorized. Is there any other way to verify users access to storage bucket object.
Google recommend to not use ACL because it's hard to manage and to have a global view on the authorization.
In most cases, Cloud Identity and Access Management (Cloud IAM) is the recommended method for controlling access to your resources.
Caution: Permissions can be granted either by ACLs or Cloud IAM policies. In general, permissions granted by Cloud IAM policies do not appear in ACLs, and permissions granted by ACLs do not appear in Cloud IAM policies. The only exception is for ACLs applied directly on a bucket and certain bucket-level Cloud IAM policies, as described in Cloud IAM relation to ACLs.
IMO, the best pattern is to have a database on your side with the file on GCS allowed per user. You can store these in Firestore: affordable, pay as you use, generous free tier. For downloading the video, you can generate a temporarily access to the user by generating a signedUrl.
As per mention Guillaume Cloud Storage use the ACL pattern in order to have a control to the access of the resources stored in their buckets.
Nevertheless, when you need to storage wide objects per user in this case a video, you can store these in Firestore: affordable, pay as you use, generous free tier. This is a very suitable option since Firestore can use as another resource
Is recommended for this scenario generate a signed URL
I use Google's Firebase Storage through the Java Admin API to store files in a Spring Boot application. For security reasons, I create a separate storage bucket for each customer organization. Since I blow away my test environment frequently, I delete and create these storage buckets often. I'm looking for help to get these buckets quicker into Firebase.
Here's what I currently do:
My Spring Boot application creates a bucket with the Google Cloud Storage libraries per the Firebase Storage documentation.
I add the Google Cloud Storage buckets to Firebase by importing them in the Firebase Storage web console. I can import multiple buckets at once.
I apply the default security rules to each Firebase Storage bucket. I can only do this one bucket at a time.
I want to automate steps 2 & 3:
From what I can see in the Firebase docs, I can't do steps 2 and 3 with the Java Admin API.
I can probably automate step 3 through the Firebase CLI tool. For that, I need to set up a "deployment target" that includes all the buckets. I have to add the buckets by name, one by one, and can't use any wildcards here. But my bucket names include database IDs which will be pretty much the same across my environments. So I hope that this deployment target only changes when I add more customer organizations.
Does anybody know of better ways to automate steps 2 and 3?
I decided to change my approach: I now put all customer organizations into one bucket.
It's just too much work to deal with the different buckets now. With one bucket, I just delete all the folders in there which seems simple for now in the Firebase Storage web console.
I'm not sure how my project would behave with hundreds or thousands of buckets. On the contrary, it seems that having thousands of folders within a bucket is a valid use case.
The lack of functionality for Storage buckets both in the Firebase CLI and the Google Cloud SDK indicates to me that you shouldn't have many buckets in your project.
I am running scripts to interact with Firestore (e.g. creating a doc). I've provided a service account key file to do so (tried with key files from Firebase and GCloud) - scripts run the same.
I am aware that Firebase is now built / closely linked to GCloud so I am expecting the key files to be similar.
However, the docs recommend initializing the sdk with a key from Firebase console when adding Firebase admin to your server and from GCloud Console for unit testing.
So here are my questions:
Why recommend 2 different ways to generate them? Is one more appropriate than the other?
Do service account key files generated in Firebase (1) and GCloud (2) consoles differ in terms of scope? Do they allow the same operations? Are they granted equivalent permissions?
Firebase Console > Project Settings > Service Accounts > Firebase Admin SDK > Create new private key
https://console.firebase.google.com/project/[my-project-id]/settings/serviceaccounts/adminsdk
Google Cloud Console > IAM & Admin > Service Accounts > App Engine default service account > Create key
https://console.cloud.google.com/iam-admin/serviceaccounts?project=[my-project-id]
The service account and credentials provided by the Firebase console are no different than one that you'd create in the Cloud console. Firebase is just making it easier to get started, so you don't have to learn the Cloud console. If you want to use the one provided by Firebase, fine. If you want to use one you create and configure in the Cloud console, fine. The Firebase service account should be visible in the Cloud console just like any other. When it comes to assigning permissions to individual products, you can still choose either one to work with. It's up to you.
I'm familiar with using Cloud Firestore when created through Firebase, but I've created a Cloud Firestore as a service within Cloud Platform and I can't figure out how to have a client access that database. I was expecting there would be someway to generate a GoogleService-Info.plist so that my iOS app can access Firestore.
How is Cloud Firestore different when created from GCP, and how can clients access it?
If you want to access Firestore from iOS, you will still have to go through the Firebase console to add your app to the project and generate that plist file.
What you probably don't realize is that a Firebase project is just like a GCP project. Every Firebase project IS a GCP project, just pre-configured with some services and APIs enabled. Read this blog for a full discussion. If you created your project via the Cloud console, you can just as easily access the very same project from the Firebase console.
Your Firstore instance is 100% the same, no matter how you access it. All the same data and scaling behavior that you expect from Firestore. The only differences lie in how Firebase client apps add special mobile functionality. Read this blog for a full discussion specific to Firestore.
Bottom line is that, for use with mobile apps, you should still use the Firebase console to set that up. You can use both console together at the same time. They show almost entirely the same data, but Firebase is simplified for mobile-centric use.
I have a backend in golang and was wondering how I can connect to Firebase storage to create/delete buckets and add/delete files. Can I use the Admin sdk. I found the client storage lib in golang for google cloud storage. Can I use that? And whats the difference between firebase storage and google cloud storage?
The app I'm working on connects to Firebase Storage Buckets via the Admin SDK, but we're using Firebase Functions in Node.js. However, it looks like the Admin SDK in Go offers the same Storage access, and it's documented (with example code in Go) here:
https://firebase.google.com/docs/storage/admin/start
I like using Admin in Firebase, because you don't have to worry about project configuration and authentication to the various services. Firebase storage is google cloud storage, but with a nice wrapper and well-integrated into other aspects of your Firebase project. You get some limitations as a trade-off for all of that convenience, but unless you run into a feature of Google Cloud that you absolutely need and doesn't exist in Firebase, I'd stick with the Firebase (and Admin) version.