I'm using Firebase 3.4.1 javascript API and trying to persist several string content into storage engine.
The first ones are successfully persisted, but quickly, I get lots of errors :
{"code":"storage/retry-limit-exceeded","message":"Firebase Storage: Max retry time for operation exceeded, please try again.","serverResponse":null,"name":"FirebaseError"}
Is there any storage limitation on allowed writes per second ? Tried to browse the website/FAQ but didn't see any of this anywhere.
Note : I recently migrated to Blaze account, but it doesn't seem to change anything.
Related
This question was previously closed, telling me to "update the question so it focuses on one problem only;" I don't know what the problem is, and if I did, I wouldn't be posting this question. Regardless, I'll make some clarifications here:
I was previously using just the normal Firebase module (the one imported using "npm i firebase"); everything worked perfectly before. The issue has to do with the authentication (as far as I am aware) with the Firebase Admin SDK. I don't understand how I'm supposed to send this to the Heroku build without revealing the service account key JSON file on my GitHub.
As for the GOOGLE_APPLICATION_CREDENTIALS path, is there a way where I don't have to set it every session? The Heroku app restarts once a day, and I would need to somehow automate this entry process (or skip it entirely). That's the way I currently understand it. Here's a quote from a previous answer:
When I set the GOOGLE_APPLICATION_CREDENTIALS path, doesn't this only set it on my local machine?
Environment variables only work on the individual machine and process where they have been set. If you want it set on another machine and process, you will have to arrange for that separately. According to the documentation:
Set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the file path of the JSON file that contains your service account key. This variable only applies to your current shell session, so if you open a new session, set the variable again.
My main question here is as follows: "I implemented the Firebase Admin SDK incorrectly. How do I do it the right way?"
Even just posting a link to guides that would help would be appreciated (although I understand this is typically discouraged as links sometimes break).
Original:
Note: this is my first time using the Firebase Admin SDK, so I'm really not sure what I'm doing (although I have used Firebase quite a bit).
Recently, I decided I would go back to one of my older Discord bots and actually authenticate its requests to Firebase properly (I hadn't done this previously as I've never authenticated from a server before and didn't think it was possible). I discovered the Firebase Admin SDK, which sounded perfect for my needs (the bot is being hosted on Heroku, for the record).
I found this guide: https://firebase.google.com/docs/admin/setup, but there's a few things I can't wrap my head around (note that these are purely rhetorical, you don't need to answer them in your answer; I'm just providing them so you can understand my thought process):
When I set the GOOGLE_APPLICATION_CREDENTIALS path, doesn't this only set it on my local machine? I could also try running the export command on the server (using "heroku run" in the CLI), but then the path would be pointing to a file that doesn't exist on the server (since the service account key JSON file is on my local machine). Do I need to set an environment variable in Heroku or something?
How does "admin.credential.applicationDefault()" know how to get the credentials?
I can't find any other guides that make sense.
The way I currently have it setup must be wrong, since reads and writes fail silently.
Firebase setup code:
// Setup Firebase:
const admin = require('firebase-admin');
// Initialize Firebase:
admin.initializeApp({
credential: admin.credential.applicationDefault(),
databaseURL: "https://<APP>.firebaseio.com" // I removed the actual <APP> name to ask this question
});
let database = admin.database();
Things like database.ref("test").set("Hello World!"); don't change the data in the database, and no errors are thrown (I've also tried attaching a .then and a .catch to the end of this; still nothing). This was working before I switched over to the Firebase Admin SDK (I was just using the "firebase" module previously, rather than the "firebase-admin" module that I'm now using). The same goes for reading data.
Any help would be appreciated.
Here was my problem:
I was sending res.status(200) outside of the async firebase call, killing the request before firebase had a chance to finish. Somehow localhost allows this to work properly but when its hosted things go sideways.
so I had this
fireabse.database().ref('parent/foo').set('bar');
res.status(200)
I needed this:
firebase.database().ref('parent/foo').set('bar').then(() => {
res.status(200);
});
In my Flutter/Dart mobile app I make use of Firebase RTDB persistence to enable offline use of the app.
My understanding is that to enable persistence you have to make the call, as per the following piece of code, before using any database references to eg. query the database. I use the following piece of code to enable persistence immediately after loading the app and it works fine:
FirebaseDatabase firebaseDatabase = FirebaseDatabase.instance;
bool _success = await firebaseDatabase.setPersistenceEnabled(true);
print(_success); // Prints true, so persistence is set 'on'.
When I logout of the app I attempt to turn persistence off with:
bool _success = await firebaseDatabase.setPersistenceEnabled(false);
print(_success); // Prints false, so persistence is still 'on', ie. the call failed.
I assume the reason persistence cannot be turned off is because there have been calls to db references prior to trying to switch it off.
This leads to three questions, I guess:
Should I be worried about turning it off at all, when I logout? The reason I attempt it is good house-keeping, mainly. I clean up shared preferences, close keepsyncd's, etc when logout is run. Also, though, the user can have multiple userids to login and I want to make sure that I am not retaining persisted data from their previous login id.
Related to 1, does setting persistence to false clear the cache of
data and potential queued calls to the db?
If the answers to 1 and 2 are 'yes', how can I switch persistence off given the code I'm using to do so keeps telling me it failed?
The typical way to handle this is to enable persistence once a user logs in.
Once disk persistence has been enabled and your app has used the database, it cannot be turned off. The documentation says this about it:
The returned Future will complete with true if the operation was successful or false if the persistence could not be set (because database references have already been created).
That last bit is clearly the case for you: you've been using the database already, which means that disk persistence is on.
To your specific questions:
Unfortunately the data in the local cache cannot be cleared up through the API at the moment. It is a valid feature request, but for now you'll have to assume that any data on the device can be seen by any user on that device (or device profile).
Disabling disk persistence keep the client from adding data to the cache. It does not clear any existing data in the cache.
I just set up a new project for Firebase and it is requiring me to enable Identity Toolkit API.
This is a problem because, even though I'm wrapping the firebase.auth().signInWithEmailAndPassword() in a try catch, the Identity Toolkit still posts and I can't catch the error.
It causes security risks like this when displaying post error.
errors: [{message: "EMAIL_NOT_FOUND", domain: "global", reason: "invalid"}]
Which means a malicious user could try to log in until they don't get this error message to see if an email exists.
I have looked through https://developers.google.com/identity/toolkit/migrate-firebase but I am not clear on what it is trying to do.
The other problem is it costs money:
Free
price/count
0 - 50K
count/month
$ 0. 0055
price/count
50K - 100K
count/month
How can I use Firebase without the Identity Toolkit?
This change should be done by the Cloud Identity Platform engineering team and you need to create a private ticket in the Issue Tracker
Use fireabase CLI
Please install firebase-tools
Please check this url
https://firebase.google.com/docs/cli
I have created a brand new free tier project, cloned Puppeteer Firebase Functions demo repository and only changed the default project name in .firebaserc file.
When I run the simple test or version functions I get the correct result. When I open the .com/screenshot page without any parameter I get correct ("Please provide a URL...") response.
But when I try any url, i.e. .com/screenshot?url=https://en.wikipedia.org/wiki/Google I get Error: net::ERR_NAME_RESOLUTION_FAILED at https://en.wikipedia.org/wiki/Google thrown in response.
I tried looking for any name resolution errors related to Puppeteer but I could not find anything. Could this be a problem of using free tier?
The free Spark payment plan restricts all outgoing connections except those API endpoints that are fully controlled by Google. As a result, I expect that puppeteer would not be able to make any outgoing connections to external web sites.
Let's see if you experts have a clue of what's going on here.
Context
We have a web application running on Azure Web Sites. This WebApp uses OWIN + OpenID Connect to authenticate users against an Azure Active Directory tenant. Also the application uses the Azure AD Graph API to collect some data of the directory.
We based our code on this sample project provided in GitHub: https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet
Issue
The WebApp was working perfectly some hours ago (authenticating to the AD and fetching data from the directory), but then the weirdest thing happened to us. Today we found that we could still authenticate against the AD but the Graph API was throwing errors almost randomly.
We traced the error down to a specific request, when trying to get a specific user by ObjectId in a synchronous way:
Claim claimObject = ClaimsPrincipal.Current.FindFirst(Helper.Constants.ADTenant.ObjectIdClaimType);
string userObjectID = claimObject == null ? string.Empty : claimObject.Value;
ActiveDirectoryClient client = AuthenticationHelper.GetActiveDirectoryClient();
List<IUser> users = client.Users.Where(u => u.ObjectId == userObjectID).ExecuteAsync()
.Result.CurrentPage.ToList();
The thing is the last line throws an exception regarding the OData model:
"A value without a type name was found and no expected type is available. When the model is specified, each value in the payload must have a type which can be either specified in the payload, explicitly by the caller or implicitly inferred from the parent value."
We started slicing the last line of code into pieces as follows:
IReadOnlyQueryableSet<IUser> queryUsers = client.Users.Where(u => u.ObjectId == userObjectID);
IPagedCollection<IUser> pagedUserCollection = queryUsers.ExecuteAsync().Result;
List<IUser> users = pagedUserCollection.CurrentPage.ToList();
And found the exception was throwing in this line:
IPagedCollection<IUser> pagedUserCollection = queryUsers.ExecuteAsync().Result;
Weirdest thing is that this line was executing fine yesterday and today started failing without explanation.
Does anyone know what are we doing wrong? Why did it start failing today?
Remarks
We are using api-version=2013-11-8. We kept the Azure AD Graph API Client Library on version 1.0, as in the sample on GitHub.
Folks,
First of all - many apologies for introducing this problem. The underlying problem is that an entity (User entity in this case) was updated on the service side, with a new collection (AlternativeSignInNamesInfo). Typically adding new entities, properties, collections and complex types should not cause a breaking change for the client library. However due to an issue in ODatalib, unknown collections are not simply ignored.
I totally agree with the sentiment on this, and we absolutely do NOT want to have apps that take a dependency on the Graph Client Library be subject to ANY outages. We are working with the ODatalib team to get this issue rectified, so that this is no longer a problem with our Graph client library moving forward.
In the meantime we are in the process of rolling back our Graph service, so that 2.0.5 should start to work again. Version 2.0.6 should also work - as long as you don't try and post to the new collection on the User object (AlternativeSignInNamesInfo).
UPDATE: The Graph service has been rolled back. I’ve also verified that getting a user through Graph Client Library 2.0.5 AND 2.0.6 both work.
Hope this helps and again sorry for any issues caused here.
I had the same problem just now! I have an application which have been working for a couple of weeks and hasn't been changed. I've got it working by upgrading "Microsoft.Azure.ActiveDirectory.GraphClient" from version 2.0.5 to 2.0.6
Yes upgrading the graph client Nuget package to the latest 2.0.6 fixed this problem. I had a similar panic this morning too. It's an unbelievable fact that Microsoft rolled out a new version of the dll which breaks applications run on previous version!
My team had similar experience. After installing 2.06 our code started working again. Took the entire day with first discovering, fixing, and then testing the solution.