Android device still receives push from old installationId after app re-installed

[macmoe]

I'm seeing the same issue that @jiawenzhang had in parse-community/parse-server#1705

Here is the issue:

• Install app on Android phone, open app and register with parse-server (as user A), get installationId_1
• Uninstall app and re-install app on the same phone, open app and register with parse-server (as user B), get installationId_2.

Note that the app on this phone is now associated with installationId_2 (as user B). The installationId_1 should not be valid.

• Now send a push notification to the parse-server targeting installationId_1, the app still receives the push even when its installationId is not installationId_1.

The parse-server is showing the following in the log:

verb parse-server-push-adapter GCM sending to 1 devices
verb parse-server-push-adapter GCM GCM Response: {
verb parse-server-push-adapter GCM "multicast_id": 7047466558839750000,
verb parse-server-push-adapter GCM "success": 1,
verb parse-server-push-adapter GCM "failure": 0,
verb parse-server-push-adapter GCM "canonical_ids": 1,
verb parse-server-push-adapter GCM "results": [
verb parse-server-push-adapter GCM {
verb parse-server-push-adapter GCM "registration_id": "APA91bEB01Bmhz3g0ZMRqBJIwg-DbQzNnvYeZxJKoj0ixVYFBW9UN2zQIMiDV86FWDDqHlJInaA9h_Mb-xV3tfCUNk2mpUdAjeYi7AdM6ggImQbATHKEp24Xg7yyS76nNLH1UDXqiMxP",
verb parse-server-push-adapter GCM "message_id": "0:1475256512754990%d7f644cef9fd7ecd"
verb parse-server-push-adapter GCM }
verb parse-server-push-adapter GCM ]
verb parse-server-push-adapter GCM }

According to GCM, the app-server (parse-server) should be updated to use the registration_id that was returned:
https://developers.google.com/cloud-messaging/registration#how-uninstalled-client-app-unregistration-works

The problem is I don't want any notifications to be successfully sent with the installationId_1.

If I try to duplicate this same issue with the production api.parse.com and SDK, I can't duplicate it.

NOTE: GCM states "Eventually, the registration token (installationId_1) will be removed and the server will get a NotRegistered error" - Does anyone know how long this would take?

[GongChen1107]

I have this problem too.

[learner88]

I am also facing the same issue. Targeting older installations also delivers notification which shouldn't be the case.

[flovilmart]

The installationId is generated when the user installs the app. Upon app update, it is reused. When the user delete the app, there is no known mechanism to persist that value across and reuse it if the user decides to delete the app.

As the documentation mentions, at one point, the old token will be marked invalid by GCM.

I am not sure if there is any way around that, to invalidate the token as soon as the app is deleted.

[olidroide]

Hi @flovilmart I have the same problem too.

Maybe the problem is at the start/init a new parse installation from device. The Parse server can check the new installation and force to remove invalid token... I notice it happens only with my parse server machine and not with Parse.com server machine (old one).

Any thoughs?

[flovilmart]

remove invalid token...

How do you suggest we remove the invalid token? Both installations are independant i believe, or is the token the same?

[olidroide]

I believe the token registered in GCM is the same for different Installations in Parse. I don't know exactly if the problem comes from Android SDK Lib or from Parse Server or combination of both.

The user @inlined has a open discussion to improve the Android SDK with FCM, and I think this adapter must manage the new FCM system (GCM v4). What is the time flow to merge his proposals?

My skill is Android based, and my feeling of this issue it happen to me after migrate from Parse.com to my own parse server, for that I update the Android libs and add the GCM tokens... Maybe some part of code Parse server is missing or some merge in Android Lib cause this problem... I found several issues with the same problem:

http://stackoverflow.com/questions/28050986/how-to-avoid-installation-duplicates-using-parse/33306713#33306713
http://stackoverflow.com/a/27259926/481637
http://stackoverflow.com/questions/27863217/parse-push-receiving-pushes-from-previous-installation
#40

But any of them works on current state. I don't know how to deal with this issue.

[posativ]

Same here. Uninstalled and re-installed an application multiple times in a few days. Now I receive 3 push notifications for a single push.

[jeacott1]

@olidroide, the token registered is not always the same unfortunately. recent testing with a samsung s6 in particular always yields different tokens and installation ids on every reinstall.

I'd like to know if anyone has any strategies at all for responding to apns bad token exceptions when parse-server supports multiple certificates, and dev/prod config. how do you reliably know when a token is actually bad, and not just that the wrong cert is being tried?

[flovilmart]

The only way to know with the non HTTP/2 APNS API is the apns feedback API which is not implemented at the time being.

[jeacott1]

even with the http/2 api, if you have multiple certs loaded, or switch from dev->prod, wont the api report bad tokens because the particular cert/dev/prod setting combination doesnt match the current device?

[flovilmart]

To be determined (i.e., didn't test myself) but it seems that one could make the difference give the response code with the HTTP/2 interface https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html

(Bad Request 400 vs inactive 410)

[inlined]

For Apple, you can also eventually find out from the normal TCP connection because Apple eventually hangs up on you. I wouldn't recommend actually implementing this. Parse used to support device token cleanup in the pre-beta days but it was turned off because deviceToken is an immutable field in Installation. You'd only be able to delete the token by deleting the whole row. If the device only turned push off rather than deleting the whole installation then you'll run into issues when the device only does delta-uploads for its existing state. It's going to do a PUT but the record won't exist anymore and ParseServer will return an error. I don't recall whether an error like that could still cause PFInstallation.saveEventually to break the entire networking queue.

For GCM that should have been fixed (according to @bnham it had been in the original server). If/when Parse updates to FCM (or even GCM v4) that's implemented in a way that makes client-only revocation easy.

[olidroide]

thanks @jeacott1 what do you think about the repeated push issue? Are you agree with @inlined this problem will solved when Parse update to FCM (or GCM v4)?

@flovilmart do you have a deadline or date when this update happen?

Thanks everybody.

[flovilmart]

As @inlined mentions, deleting the deviceToken from the server may be problematic, also, we will haven't integrated the HTTP/2 APN endpoints. On Apple devices, that push will simply be marked as non sent.