1 Are FCM token and Instance Id one and the same?
In my next questions, I suppose there aren't.
2. Is it possible to register an app instance ID twice to the same topic?
FCM token and Instance Id expire and are refresh.
3. Do we need to subscribe to a topic again after a token refresh?
I suppose we do.
4. Should we listen to a FCM token refresh or to an Instance Id refresh?
I am confused because the Firebase iOS API to register to a topic is:
[[FIRMessaging messaging] subscribeToTopic:#"news"]
It is not explicit which token is involved. My guess is that the internal logic uses the Instance Id because the server API endpoint is https://iid.googleapis.com/iid/v1/IID_TOKEN/rel/topics/TOPIC_NAME
However the Firebase documentation only mentions FCM token refresh and how to monitor them.
The InstanceID and the Token are different. See an explanation of the InstanceID in my answer here, and a general explanation for the token in my answer here.
Usually tho, the token (when printed) contains the InstanceID as well. It may be a format Google chose to make sure that the token is unique, or to connect it to a specific device. I can't say for sure.
There is no way that you can duplicate a subscription. Whenever a token is refreshed, the corresponding subscriptions are kept by the new token.
No. See #2.
It uses the token. The InstanceID is just the ID for the app instance. The token is what FCM needs to send the message.
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 have an app which is receiving a token from firebase. From what I understand, the next step would be to assign that token to a user in my database, perhaps in a "lastFirebaseToken" column. Then I could call the firebase api using this token to send messages to a specific device. If any of this is wrong, my question won't make sense, but assuming all of the above:
Would there ever be point at which a token that was assigned to a device in the past gets re-assigned to a different device?
In any case, I'll probably make the lastFirebaseToken column UNIQUE, but I still find this question important to my fundamental understanding of firebase.
No, the tokens should be unique.
According to the documentation:
Registration token
A unique token string that identifies each client app instance. The
registration token is required for single device and device group
messaging. Note that registration tokens must be kept secret.
I can't find any place in firebase docs, where indicated that received tokens are unique. I will be grateful if someone could point me such place. Main question - should I make unique constraint in database for such tokens. Thx!
According to documentations, they're unique, but you can't bind them to a specific device since they might change.
Documentation for IOS:
The registration token may change when:
The app is restored on a new device
The user uninstalls/reinstall the app
The user clears app data.
Documentation for Android:
The registration token may change when:
The app deletes Instance ID
The app is restored on a new device
The user uninstalls/reinstall the app
The user clears app data.
When I search for Are Google Cloud Messaging tokens unique, the first result is this page from the documentation, which says:
To verify that they can send and receive messages, client apps must register with GCM. In this process, the client obtains a unique registration token...
Firebase Cloud Messaging Instance ID Tokens uniquely identify an instance of an app. They are globally unique.
Whether you should mark the column in your database as unique depends on your usage of that column. As yourself questions like: what bad thing will happen if a token is present twice in this table? Will marking the column unique prevent the bad thing from happening?
As per my experience I have noticed that the FCM token is changed in three scenario they are as follows:-
When the application is uninstalled or reinstalled.
When the data of the application is cleared.
When the application is installed in new device.
Note:- There is no way to keep the FCM token same.
Yes, they are unique but they are not constant. Means for first time when I had installed one application then FCM token was let's say abcd but when I uninstalled the app and again installed the same app then my FCM token was not abcd but something else.
So, FCM tokens are unique but they are not constant, they keep on changing when we uninstall and install the application.
I'm looking at implementing messaging between mobile and browser apps using Firebase cloud messaging and i have a few questions, that the docs don't seem to answer.
For being able to receive messages, you need a Registration Token (RT).
Messages can be send to a RT, to a topic or to a device group notification_key.The RT can also be used:
directly
to subscribe to a topic
to add to a device group
The RT can also expire/change.
In my app, I'm maintaining a list of RT per user. Now, when the RT changes:
Do I have to unsubscribe the old token and subscribe the new token to topics?
Do I have to remove the old token and add the new token to device groups?
Is it possible to get information about device groups/topics for a token?
Can I add a token to a device group more than once?
Can I subscribe a token to a topic more than once?
Will multiple subscriptions/additions of the same token result in receiving duplicate messages
Sorry, that's a lot of questions, but I guess, for somebody who has gone through this, it should be pie ;)
Do I have to unsubscribe the old token and subscribe the new token to topics?
AFAIK, you don't have to unsubscribe the old token, since it will be discarded by FCM itself. For the new token, yes, you'll have to subscribe it to the topic you need. The usual thing is done (in Android) by having subscribeToTopic() in onTokenRefreshed().
Do I have to remove the old token and add the new token to device groups?
Yes. You have to handle the mapping/relationships for Device Group Messaging. See my answer here. This is different from topics. The token will be invalidated, but will be kept as part of the list of registration tokens for the corresponding registration key.
It's why there's a possibility to receive a NotRegistred error on one of the tokens if you send to Device Group. :)
Is it possible to get information about device groups/topics for a token?
For Device Group Messaging (same with #2), the developer (you) have to manage these details yourself. For topics, you can use the InstanceID API. Specifically, set details parameter to true:
[optional] boolean details: set this query parameter to true to get available IID token details, including connection information and FCM or GCM topic subscription information (if any) for the device associated with this token. When not specified, defaults to false.
Can I add a token to a device group more than once?
Ahmm. Yes. Do you mean the same token? If so, I haven't tried it yet. Might as well do some checking on the client side before adding.
Can I subscribe a token to a topic more than once?
If you mean re-subscribing, then yes. If you mean duplicate request to subscribe, I think the result would still be a success. No changes in behavior though.
Will multiple subscriptions/additions of the same token result in receiving duplicate messages?
Tested it out. You won't receive duplicate messages for both duplicate topic subscriptions and adding the same token to a device group. It seems that FCM ignores the request to subscribe/add a Registration token if it's already subscribed/added to a device group.
With Firebase Cloud Messaging for Web,
How do I maintain the list of valid tokens in my database? For example I've noticed when a user turns off notifications and revisits the site, a new token will be generated and the old token in my database is useless.
I've also tried using Firebase messaging.onTokenRefresh() callback, but it does not get called when I turned off notifications. Also in this case, even if it did get triggered, it returns a new token that was refreshed. How do I keep track of the old token that was refreshed?
Can someone please share with me their thoughts/ways to maintain and ensure the token list in the database are valid or up-to-date?
Any feedback is much appreciated.
Thank you,
Christina
messaging.onTokenRefresh() is probably a wrapper around the event onpushsubscriptionchange.
Indeed that event is currently only called when the subscription is enabled (or enabled again), but not when the permission for push notifications is revoked. So at the moment you can only know that an endpoint has expired when you try to send a notification to it.
More details:
http://blog.pushpad.xyz/2016/05/the-push-api-and-its-wild-unsubscription-mechanism/
In any case you can use the callback to send any new token to the server: at first you will have two tokens stored for the same browser, one expired and the other valid.
Some problems arise if you have data associated to the endpoint (e.g. tag) that you want to preserve during the endpoint change: see the blog post for some suggestions.