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.
Related
I've incorporated Firebase Cloud Messaging into my app. After messing around, I kind of understood the premise of how it operates. So, as a result, I structured my code so that when users sign up the FCM token is stored. After creating two accounts, I realise both FCM tokens for the user were the same.
Looked online and sorted this issue, and now I can refresh the token on launch, and still append the new FCM token when users initially sign up.
So now, I ask the question - Users are created with a fcmToken field (which I can refer to in my code), however, due to the fact a new token is generated on launch each time does this render the token(s) stored for each user useless? Or can I still push to the specific user using the fcmToken?
I've looked online, but can't seem to find an answer.
FCM tokens don't uniquely identify an individual end user. They identify a specific installation of an app on a specific device. When sending with that token, it doesn't matter who is signed in to the app (or if anyone is signed in at all) - the app will still receive it and need to figure out what to do with it. It's up to you to decide what to do with that message, given the sign-in state of the user. If you expect that your app could have multiple users sharing a single app on a single device, then you will probably want to send something in the payload to determine who that message was intended for, if necessary.
#doug great answer, but there's a common implementation problem when people share a device, so please add a warning, something like: often only the last logged in user should receive push notifications, otherwise he could see messages from the person who was logged in before. your backend should not only store all the devices a user is logged in, but also for each device who the last active user is and check this upon sending a push. the question whether you receive push or not when logged out is a common topic, too.
The way I understand Firebase Cloud Messaging at the moment, I will want to save all FCM tokens a user might have across devices to my backend and send a notification to all of these tokens at once when I want to notify that user about something.
Multiple tokens
Until this point, I assumed that each device only has one active token, however, reading this section of the documentation:
To enable this feature, make sure you have each sender's sender ID. When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field, using the token retrieval method for the given platform
Does this mean that I might need to target multiple active tokens per device?
Deletion
And now coming to the really important question. A simple solution to the above problem would be to simply store every token I ever retrieve in the backend and thus ensuring that my user will always receive the message.
However, what do I do if the user signs out of my app using Firebase Authentication, i.e. a different account is used in the same app on the same device?
I assume that the tokens I sent to my backend for this device will still be active - so now this user will receive notifications from another account because that account was signed in on the device previously.
I do have access to the current FCM token and I could delete that from my backend before signing out the old user, but considering the "Multiple tokens" section: how do I make sure that I can delete all FCM tokens of the old user from my backend?
Uniqueness
Additionally, assuming that old tokens are just dead for the device (will not trigger notifications anymore) when new ones are generated, can I be sure that this token will never be assigned to another device in the future?
TL;DR
How can I make sure that I have the correct FCM token(s) for my user stored in my backend and more importantly: how can I ensure that no tokens of other users are saved for some user in my backend?
I read through:
https://stackoverflow.com/a/40158260/6509751
However, I still do not know how to deal with multiple tokens.
Does this mean that I might need to target multiple active tokens per device?
An application has a single active token for each sender ID. It's fairly uncommon to have multiple sender ID, and you'd usually know if if you do. If you're sending from a single back-end, there's usually no need for having multiple sender IDs.
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.
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.
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.