This is the documentation for the error:
The provided registration token is not registered. A previously valid registration token can be unregistered for a variety of reasons, including:
The client app unregistered itself from FCM.
The client app was automatically unregistered. This can happen if the user uninstalls the application or, on iOS, if the APNS Feedback Service reported the APNS token as invalid.
The registration token expired. For example, Google might decide to refresh registration tokens or the APNS token may have expired for iOS devices.
The client app was updated, but the new version is not configured to receive messages.
For all these cases, remove this registration token and stop using it to send messages.
In order to figure out what the error is, I first need to narrow it down to one of the following four reasons. But first I have to understand what they mean.
App Unregistered: What does it mean for an app to unregister? How can I test it?
Invalid APNS token: How can I check this?
Expired token: The tokens are brand new, so this seems unlikely, but how can I validate this?
Not configured to receive messages: It's the same app that's generating these tokens, so what else needs to be done? How can I test this?
Overall, my big question is, how can I test any one of these 4+ circumstances in which this error might be thrown? What can I do to make progress here?
Related
I am not sure what a proper FCM token handling mechanism would be so I’m writing our process down here just to get some validation or suggestions for improvements:
Fetch FCM token on client Login (Flutter)
Save FCM token on our Database (Using our REST API)
Delete FCM token on Logout (Using our REST API)
Q1: Should we be getting the FCM token more often than just on login? AFAIK, FCM token only changes on app re-installs, clearing cache, etc. Does this also include app-updates from the PlayStore? In that case, should we save the FCM token on every app launch since the user will remain logged in after an app update and hence we wouldn't trigger the save FCM call.
Q2: Did I mention the right way to handle deleting FCM tokens from our DB? We don’t want the user to keep getting notifications once they have logged out.
Q3: An add-on idea is to send the device_id to the server along with the fcm_token so that server deletes all previously saved FCM tokens for that device_id. This is useful to not have useless tokens on the DB from cases where the user uninstalls the app without logging out (which means that the DELETE fcm_token call never went through.)
The FCM token is refreshed under conditions that you don't control, and those conditions have even changed over time. To handle token updates properly, you'll need to implement both initially getting the token and then monitoring for token updates.
Note that FCM tokens are not associated with a user. It is fine if you want to associate them with a user, but it's up to your application code in that case to maintain the association. So that for example includes deleting the token from your database when the user signs out, as you're doing in step 3. 👍
For keeping your token registry clean, you can indeed do this proactively as you intend, or reactively as shown here: https://github.com/firebase/functions-samples/blob/master/fcm-notifications/functions/index.js#L76-L88
Hi Rohan fundamentaly you should use below logic to save tokens on server.
Step1:
as soon as you get token in callback whether new or same try to save it localstorage.
Step2:
Call your REST API to save it to your server. it is upto you if you want to send unique user identifier along with the token.
Step3:
It is obvious you will recieve token callback a lot of time so you can check whether you have similar token in localstorage, it means you have the token on the server so no point calling REST API.
Step 4: Now your app can send events back to server and based on it trigger Push notifications to the users.
Step 5: You can Add/update user token based on uniqye user identifier. In some cases a user can be guest user, so your app should generate guest userId and link it with token.
Stay safe.
I'm doing analysis on Firebase Token and understood below points:-
-> A Firebase token is saved in database which will be used for sending notifications.
-> The token generally do not expire except in the following cases:
- 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 we use a token which is expired we get errors like Not Registered from the response while sending messages.
-> To avoid the error, we should be deleting the token from database.
However I have found that If we login to a cloud application (which is my app currently), a new fcm token gets generated when i logged in to a new browser say FireFox, Edge etc.
So, the token is generated based on browser or System IP or what exactly the Fcm uses to generate a token ?
The method used to generate the token is an implementation detail, and you should not depend on that to build your app.
A token uniquely identifies a device. Each device receives messages independently of each other, and does not know anything about the user of that device. It's expected that if a user signed into an app on multiple devices, that each device would generate a unique token. If you want to send message to a user, you will have to map each of the user's device tokens in your own database, and send the message to each of them, or only the ones that the user chooses.
You can expect that device tokens might change over time. If you send a message to a device, and the API tells you that the token is not valid, you should simply delete it from your records.
In our app we use Firebase Cloud Messaging to send push notifications to our users. We save the registration tokens of our users in our SQL database and when a user logs in or out we use the Firebase API to manage his topic subscriptions.
This works out pretty well in most of the cases but now the topic subscriptions return the following error for some of our registration tokens:
The provided registration token is not registered. A previously valid registration token can be unregistered for a variety of reasons. See the error documentation for more details. Remove this registration token and stop using it to send messages
In which cases does Firebase delete previously registered registration tokens? I can not find any specific information about this in the error documentation.
Thanks for your help!
From the documentation:
A previously valid registration token can be unregistered for a variety of reasons, including:
The client app unregistered itself from FCM.
The client app was automatically unregistered. This can happen if the user uninstalls the application or, on iOS, if the APNS Feedback
Service reported the APNS token as invalid.
The registration token expired. For example, Google might decide to refresh registration tokens or the APNS token may have expired for
iOS devices.
The client app was updated, but the new version is not configured to receive messages.
According to this link, the registration token must be kept secret.
Registration token: An ID generated by the FCM SDK for each client app instance. Required for single device and device group messaging. Note that registration tokens must be kept secret.
How sensitive is the token? Can anyone with the registration token send notifications to the device? Or is the token specific to my project?
What are the risks if some else gets hold of a device registration token?
How sensitive is the token? Can anyone with the registration token send notifications to the device? Or is the token specific to my project?
Not really. If the a sender not associated with the registration token sends a message, then they're going to receive an error:MismatchSenderId:
A registration token is tied to a certain group of senders. When a client app registers for FCM, it must specify which senders are allowed to send messages. You should use one of those sender IDs when sending messages to the client app. If you switch to a different sender, the existing registration tokens won't work.
If you base it from that, it does seem that keeping the registration token a secret is not that much of a thing. But what if a scenario happens that an unauthorized user gets an access to send messages, if he doesn't know/have the registration tokens, then it's pretty much useless. Just think of it as another safety measure.
What are the risks if some else gets hold of a device registration token?
From the scenario I mentioned above, if someone (unauthorized users) got access to send messages and the registration tokens, then they can pretty much send anything towards it.
I'm looking to accurately track users who decide they no longer want receive push notifications from my app OR users who delete the app.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/BinaryProviderAPI.html
From Apple documentation here there are some push error codes but none seem to fit clearly with user token removal. A
https://developers.google.com/cloud-messaging/http-server-ref#table9
From the Google docs this following error code seems to be close to what I want.
Error
Unregistered Device
HTTP Code
200 + error:NotRegistered:
Recommended Action
An existing registration token may cease to be valid in a number of scenarios, including:
If the client app unregisters with GCM.
If the client app is automatically unregistered, which can happen if
the user uninstalls the application. For example, on iOS, if the APNS
Feedback Service reported the APNS token as invalid.
If the registration token expires (for example, Google might decide
to refresh registration tokens, or the APNS token has expired for iOS
devices).
If the client app is updated but the new version is not configured to
receive messages.
For all these cases, remove this registration token from the app server and stop using it to send messages.
It seems here there is no way to differentiate between app uninstalls / token removals & token expiration
I already am sure uninstalls can't be track with Apple.