To call the Datastore.export() API I need to provide a GCS bucket name in the same region as the Datastore I'm exporting.
I checked with node.js' #google-cloud/datastore Datastore instances seem to have no .location property or something similar. Also, the Google provided Datastore libraries in other languages seem to lack this functionality.
With other Google APIs you usually have a way to get the Location of the resource. E.g. in GCS: Storage().bucket('mybucket').getMetadata().location -> 'EU'.
How to view Google Cloud Datastore Region shows to get this information in a manual way, but I'm after programmatic access.
Firestore has a database get method (in preview as of 2021-12-23), that you can use to lookup the location of your database. This API will also tell you the mode of your database (Firestore native vs Datastore mode).
Related
Using Google Firebase Functions as a backend of the small application.
Functions are accessing to the Firestore and Realtime database, therefore they need service account credentials file.
On the other hand, I'm trying to automate the deployment of the functions using Github Actions.
Currently I places the credentials file inside the repository. I know that it's not secure.
What is the proper way of storing service account credentials file in this case?
Firebase projects, are, in effect, Google Cloud Platform projects.
More specifically, when you create a Firebase project, an associated Google Cloud Platform project is created for it.
Therefore the process for storing credentials is the same as in Cloud Platform, which is to say in a file, somewhere relatively safe.
This file should be accessible to your Function if it is required, and should either have its path specified as part of an environment variable or explicitly declared in code.
You are already storing it the proper way, because the improper way would be to insert the contents of the JSON file directly into code.
To prevent others from seeing the contents of the JSON file, simply set the respository as private.
I am afraid of some latency when calling Firebase API. So I would like to know where the Firebase API servers are located. Are there any documents? Please help. Thanks.
The official documentation regarding choosing locations for your project, doesn't include an option for the Firebase Authentication. So currently, there is no way to specify a particular location for storing the Firebase Authentication data.
However, when you are using Cloud Firestore, Cloud Storage, or Cloud Functions for Firebase, you're prompted to select your project's default location. On the other hand, when using the Realtime Database, you're prompted to select the location of the instance, and each instance can be in a different location.
If you are also using Analytics, you're also prompted to select an Analytics reporting location. You can select a country or region that represents the location of your organization.
Firebase docs suggest firebase auto-created keys should not be restricted and unlike other sercet keys can happily appear in website's source:
Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources; that can only be done with Firebase Security Rules. Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); however, API keys for Firebase services are ok to include in code or checked-in config files.
The API keys auto-created by Firebase, by default, have no restrictions.
Secure your database and Cloud Storage data by using Firebase Security Rules, not by restricting and/or obscuring your API keys.
However, it seems that when we include our firebase key in our source code, it can be used by a malicious attacker to call paid Google services, such as Custom Search APIs which costs $5/5000 queries, thus draining the Google console balance of a poor unsuspecting victim.
Also, it seems adding restrictions to Firebase keys is not working - either preventing the key from working or triggering a creation of a new auto-generated key instead (see here, here, here)
So should we somehow restrict the api-key,
hide the key from the website's source
or something else?
I wasn't able to find anything about he malicious attacks using an API Key auto generated and can be restricted without any problem. Most of the posts you commented on have responses on how to solve their problems with the restriction options. Also, google documentation does recommend some API Key restriction.
Also, you have the App check to limit access to the backend services in your Firebase project.
Here there is also an article about security of the API keys in firebase.
So, after testing around and looking through some pages I think it's pretty safe to let some of them unrestricted and another ones restricted depending on what they are accessing to and you shouldn't have any problem.
I have an existing Google Cloud project which uses Datastore. I'm excited by Firestore and would like to switch. According to https://www.youtube.com/watch?v=SYG-BgXoJFQ it is recommended to create a new project.
Is it possible to just nuke Datastore somehow (I don't care about the data) and start from scratch with Firestore?
If not, what are the implications of creating a new project?
If there is no data written to Cloud datastore, it's possible to convert from datastore to firestore with the following steps. I tried on 2 projects and each project took 3 minutes. The user should be the project owner to attempt:
Disable Cloud datastore API
Disable Cloud Firestore API
gcloud firestore databases create --region=us-central --project $PROJECT_ID
I have another project that has little datastore entities. I deleted them and executed the steps, but received the following error. While disabling datastore API, I read Disable Cloud Datastore API? If any resources were created by Cloud Datastore API, they may be deleted soon after Cloud Datastore API is disabled. All code that uses this project's credentials to call Cloud Datastore API will fail.
ERROR: (gcloud.firestore.databases.create) Error Response: [9] The
"database_type" field cannot be modified for this application. Note:
If data has already been written for this application, then the
"database_type" may not be modified.
The solution is to contact Google cloud support to convert from Datastore to Firestore. You need to make sure no entities exist and nothing is creating any entities.
In the case where no Datastore entities have been written, the operation should succeed:
Success! Selected Google Cloud Firestore Native database for $PROJECT_ID
It is not possible to switch from Datastore to Firestore within the same project as yet, but you may operate Firestore in Datastore mode. By creating a Cloud Firestore database in Datastore mode, you can access Cloud Firestore's improved storage layer while keeping Cloud Datastore system behavior. You may find more information of relevance by reading the "Automatic Upgrade to Cloud Firestore" documentation page.
Firebase's documentation has the following paragraph:
Using Cloud Firestore and Realtime Database: You can use both databases within the same Firebase app or project. Both NoSQL databases can store the same types of data and the client libraries work in a similar manner. Keep in mind the differences outlined above if you decide to use both databases in your app.
I can't find any documentation on how to add a Cloud Firestore to an existing project with a Realtime Database, though. I will ultimately upgrade to Cloud Firestore, but would like some time to experiment and learn before I convert the production database.
Does anybody know how to use both databases in the same Firebase project?
When you go to your project in the console and choose the Database product, you should see something like this the first time:
This is a selector that lets you choose to see either Realtime Database or Firestore in your project. You can switch between the two with this selector.
The first time you select Cloud Firestore, it will ask you to configure things. Start in "test mode" to set things up for full read and write without authentication to get started quickly, but of course your should always have rules set up in production.
After you set up Firestore, you should be able to use both client SDKs to access both databases independently.