Does anyone knows what the timing of the Firebase Cloud Functions onCreate Authentication Trigger is?
Is it like:
- User registers using SDK
- Firebase creates user in and for Firebase Authentication
- Firebase SDK sends login successful event
- Function onCreate is invoked
or like:
- User registers using SDK
- Firebase creates user in and for Firebase Authentication
- Firebase onCreate is invoked
- Firebase SDK sends login successful event
Or in other words:
Can I be sure that after a successful user registration a Firestore User Document was already created by a short Firebase Cloud Function script?
So can I be sure that when the SDK send the authentication successful callback that the Firestore user document was created?
You are given no guarantees about the timing of the delivery of events to your Cloud Function code. Of course, the system is going to try to deliver as fast as possible. But the fact of the matter is that there can be unpredictable delays at every stage through the processing of that event, so you shouldn't depend on any sort of specific timing. This is especially true when also dealing with other systems that work asynchronously as well, including Firestore (it sounds like you're implying that your function creates a document to read back later in the app).
The good news is that you can listen to the document that you expect to be created for the user, and receive it whenever it's ready.
As Doug has said, sadly there are no guarantees onCreate will be evoked in time, but here is my thought solution.
Because the onCreate hook can only access the auth user information, you will have to have a post-creation function. So I see two options:
it's worth having the post-creation function handle the case if the db record isn't created by the onCreate hook
OR
Don't even use the onCreate hook since it's almost redundant.
Related
I have a step in my new user flow where a user is registered with Firebase auth, and then a record is written to Firestore.
Is there a straightforward way to put both the user registration and the firebase write into a transaction, so if either one fails, they both fail?
Is there a straightforward way to put both the user registration and the firebase write into a transaction, so if either one fails, they both fail?
There are no Firebase products that support cross-product transactional operations. You'll have to nest both calls and always handle the errors. So do the authentication, and then write the data to Firestore or the Realtime Database.
A more convenient way of handling this situation would be to trigger a Cloud Functions in response to the creation of a Firebase user account. In this way, you will only need to handle a single operation on the client.
I have a Flutter app integrated with a Firebase Realtime Database.
I want a notification (actually an alarm kind of thing if possible), when an item (lets call it alarm) in the database is set to "true". I always see firebase_messaging plugin for notifications, but I am not sure if I'm supposed to use this plugin despite that my app doesn't have anything to do with messaging.
I am totally new to both Flutter and Firebase, can you tell me how to listen to the database even if the app is not running?
By the way, I am currently building the app for only Android, but I want to build it for IOS too in the future.
Thanks.
You can use/write firebase cloud fucntion. Using firebase cloud function you can watch any document/field and try to write trigger logic like if a field is set to true then this cloud function will throw an notification via firebase messaging.
https://firebase.flutter.dev/docs/functions/overview/
When the user is not actively using the app there is no reliable way to continue to listen to changes in the Firebase Realtime Database. To notify the user of changes to the database in that situation, you'll need to listen for those change on an environment that is always on, and then send a message to the user through Firebase Cloud Messaging.
One environment that is always in is Cloud Functions, which is also part of Firebase, and allows you to run small snippets of JavaScript code on Google's servers in response to things that happen in your Firebase project. The documentation of Cloud Functions for Firebase as example of how to notify the user when something interesting happens in the database:
Developers can use Cloud Functions to keep users engaged and up to date with relevant information about an app. Consider, for example, an app that allows users to follow one another's activities in the app. Each time a user adds themselves as a follower of another user, a write occurs in the Realtime Database. Then this write event could trigger a function to create Firebase Cloud Messaging (FCM) notifications to let the appropriate users know that they have gained new followers.
The function triggers on writes to the Realtime Database path where followers are stored.
The function composes a message to send via FCM.
FCM sends the notification message to the user's device.
To review working code, see Send FCM notifications.
I am creating a game in Unity where the user can contribute with levels using a Level Creator system.
My application is setup in a way that I just need to call the Cloud Function with the level info, and it handles duplicate entries and saves it to Firestore. All of this works perfectly.
My question, basically, is: can I have my functions only accept calls from my game? (without having my users registered?).
Naturally, I am using functions.https.onCall((data, context) => {}). In the documentation for Firebase, I noticed they use context.auth to check whether the user is authenticated or not. However, I am logging this value to the console and it appears to be undefined.
I am also confused with this line, from the same link:
With callables, Firebase Authentication and FCM tokens, when available, are automatically included in requests.
Maybe context.auth is not defined because my game isn't yet in Google Play / Apple Store? Any ideas?
Thanks to the new feature called Firebase App Check, it is now actually possible to limit calls to Callable Cloud Functions to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security that Doug describes in his answer, so that you have another shield against abusive users that do use your app.
It's not possible to restrict invocations of a callable function to just one app, and it doesn't matter if the app is published to any stores. Once you deploy a function, it's accessible to anyone with an internet connection.
The best you can do is require your users to be authenticated with Firebase Authentication in your app, then check context.auth in the function to determine if the it should do what the user wants. context.auth will be undefined in the case of no authentication. If your code determines that the function should not go any further, you can return early. But the function is still invoked.
I am new on firebase cloud functions. I would like to ask a question about always running or self-triggering functions. How can we handle these things? How can we implement always running functions or self-triggering?
Google Cloud Functions are snippets of code that run in response to events that happen somewhere else. Some example events:
a HTTPS URL is accessed, either from application code, or in some other way
a User account is created on Firebase Authentication
a node is written in the Firebase Realtime Database
a message is sent to a Cloud PubSub topic
There is no concept on a forever-running function on Cloud Functions (nor on other, similar Functions-as-a-Service offerings), although it's definitely possible to create a function that gets triggered every minute or so (like a cron job).
Currently the open sourced cloud function provided by Firebase/Stripe uses onwrite to Firebase database to trigger the charge to Stripe:
https://github.com/firebase/functions-samples/tree/master/stripe
It seems that it would be more direct and faster to just call Stripe using https trigger instead of writing to Firebase local database which syncs/writes to Firebase server database, which then triggers the cloud function call to Stripe.
Will there be any problems using Https call to trigger Stripe call? What advantages are there for using onwrite trigger instead of https?
Beginner to beginner, this is my understanding:
Let's say you have an app where a you need to
(1) sign users up for a subscription using Stripe, and then
(2) when users use the app, check to make sure their subscription is still valid.
For (1),
you'd only do this once(ish) per user, and you need to tell Stripe "make a new subscription for this user," so it makes sense to use an https.onRequest or https.onCall function.
For (2),
you'd be checking to see whether the user is subscribed many times, and you're not telling Stripe something, you're asking it about stored information: "is this user's subscription still valid?"
If you're asking about stored information, it's a lot faster to check your own database rather than to wait for a response from Stripe. You just need to make sure the information in your database (e.g. Firestore) is up to date with Stripe.
So what you can do is create a Stripe webhook that will trigger an https.onRequest function whenever there is a change to a user's subscription status. Then, your function writes the change to your database.
So, rather than ask Stripe over and over, "is this user subscribed," and wait for a slow response, you just check your own database, knowing that it's kept up to date by the Stripe webhook.