I want to generate access tokens every 15 minutes . Is there a way to implement it using timers?
Or say if i want to invoke a service every x minutes.
As of now the platform does not provide a way to run batch jobs. But any scheduler from outside can be used to invoke an API exposed by the platform.
You can set each access token to expire in 15 minutes. If an application using the token makes a request after the token has expired you can return a 401 or 403 status code, and ask developers to create a new token at that time by calling the token endpoint again.
If you really want to generate tokens in batches and store them for later use, create a script that invokes "curl" or your favorite HTTP client to call your token endpoint to generate the desired number of tokens.
Related
I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?
My question is, what security consequences would this bring? Thank you.
To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.
The convention is to send the ID token to your backend with every request. It's not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn't cost any money.
Typically what you're supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you're supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token - simply use whatever the callback most recently provided.
Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they'll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.
I've been following a tutorial to build a full stack website using firebase, react and redux. Log in sends a call to a back end function which uses
firebase.auth().signInWithEmailAndPassword for logging in. The IdToken is passed back to the client and stored in localstorage. Authentication and state persistence then relies on the client checking if the current date is past the expiry of the JWT token. API calls to the back end cloud functions also require an Authorization header using 'Bearer {IdToken}'.
This structure is causing me lots of headaches. I've done lots of reading and my current understanding is that firebase has it's own authorization persistence (?) that I can implement directly on my front end. Then using a listener I can automatically get new Id tokens on auth state change. This would solve my problem of the tokens expiring every hour. From what I've read local storage of the tokens is also a security risk.
I'm unsure as to how that affects authorization of my function calls. Should I still use the authorization header or is there a more elegant firebase way of doing that?
If you use Firebase Authentication's built-in providers, they indeed automatically persist the sign-in information information on most clients, restore it upon restart, and refresh the ID token just before it expires.
So if you use one of the standard providers, you can just get the user's ID token and then pass that to your Cloud Function.
You can even skip that step by using Callable Cloud Functions. For those, the Firebase Functions SDK passes the ID token along automatically, and the server automatically decodes and verifies it, and passes it to your code as context.auth.
I am building some internal API for my apps/website with Firebase Functions. Internal API as in to let my apps/website to process something on server side, its doesn't mean to open to public use.
My Apps is built with ionic and website is built with angular.
I noticed the one of Firebase Functions Pricing calculation include "Invocations". Is that Invocations means every time when I call the API equal to 1 Invocation? If yes, then the API might be abused by end user, since they able to view the website source and found the API.
I been searching solution in google, some of them suggest to enable authentication and cors, to avoid abuse of the usage. But authentication and cors still counting the Invocations right?
My code structure:
client call API by get/post method, pass user TOKEN that get from Firebase Authentication
request reach the Firebase Functions
server will check the preflight info by using CORS, as well as validate the TOKEN.
Return error if didn't pass on the (3), else proceed to execute the function.
So I assume if end user inspect my web source code and get the API URL, they can simply spam my API right? Then my bill will burst because of the load of Invocations.
If you suspect that your project is being abused, which is always possible, contact Firebase support to work towards a resolution.
I'm migrating to the FCM v1 API (https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages) from the legacy API (https://firebase.google.com/docs/cloud-messaging/http-server-ref) to send push notifications.
I want to know if is there some way to retrieve the canonical_id related to the token (registration_id) just like in the legacy API.
I have found nothing about it in the docs, only that the result is a Message object, and if an error occurs it returns a FcmError Object.
If I can't retrieve the canonical_id I think I would end up receiving errors of invalid / not registered token after some time (or am I wrong?), and would have to invalidate them in my database, if the user doesn't use the app during a reasonable amount of time.
AFAICT, canonical_ids haven't been used since the legacy api. See my answer here.
Registration tokens don't get invalidated on a regular basis, just on a few scenarios, where onTokenRefresh() is actually called and thus must be handled on the client side (resend the new token towards your server).
I am building a chat and I want to send message in FCM to 1000 clients in a group. The message would sent from client to group of 1000 clients (the message not pass through server). I can use the topic method, but if I want to remove a client by the group admin it's not possible. Anyone can propose a solution?
Help me please.
Topics are indeed public: you (as the developer/administrator of the app) cannot prevent your app's users from subscribing to a topic.
If you want to control the devices that do (and don't) receive your messages, you'll have to send the message to those specific devices. You do this by tracking the instance ID tokens for those devices in a database and then targeting the list of tokens when you send the downstream message.
There is an example of how to manage device tokens and send messages in the Cloud Messaging for Firebase documentation.
If you simply want to remove (unsubscribe) some specific members, you can make use of the InstanceID API, specifically batchRemove.
Manage relationship maps for multiple app instances
Using the Instance ID service's batch methods, you can perform batch management of app instances. For example, you can perform bulk addition or removal of app instances to an FCM or GCM topic. To manage app instances, call the Instance ID service at this endpoint, providing the app instance tokens in the JSON body:
https://iid.googleapis.com/iid/v1:batchAdd
https://iid.googleapis.com/iid/v1:batchRemove
Parameters
Authorization: key=YOUR_API_KEY. Set this parameter in the header.
to : The topic name.
registration_tokens : The array of IID tokens for the app instances you want to add or remove.
Results
On success the call returns HTTP status 200. Empty results indicate successful subscription for the token. For failed subscriptions, the result contains one of these error codes:
NOT_FOUND — The registration token has been deleted or the app has been uninstalled.
INVALID_ARGUMENT — The registration token provided is not valid for the Sender ID.
INTERNAL — The backend server failed for unknown reasons. Retry the request.
TOO_MANY_TOPICS — Excessive number of topics per app instance.
Example POST request
https://iid.googleapis.com/iid/v1:batchAdd
Content-Type:application/json
Authorization:key=API_KEY
{
"to": "/topics/movies",
"registration_tokens": ["nKctODamlM4:CKrh_PC8kIb7O...", "1uoasi24:9jsjwuw...", "798aywu:cba420..."],
}
Example result
HTTP 200 OK
{
"results":[
{},
{"error":"NOT_FOUND"},
{},
]
}