We are using Parse.com to send push notifications. With the announced shutdown, we're now looking into how to migrate to another service. On Android, we haven't configured any GCM sender ID so we have been implicitly using Parse.com's sender ID. That's a problem for the migration (see Urgent note for Parse Android Push users and Migrating an Existing Parse App (section Exporting GCM Registration IDs)).
Therefore, we are now preparing a new version of our Android app with our own GCM sender ID. Is there any way in Parse.com to verify which devices (installation) are associated with our sender ID? How can we check if our update was successful? Does Google provide any API for directly or indirectly checking if a sender ID works with our Google project?
Any tool or any approach that involves writing some code is ok.
Thanks for posting this question. I help work on OneSignal and I've updated the mentioned blog post based on the feedback.
The blog post now instructs users to also update their ParseInstallation to set their GCMSenderId, as follows:
final ParseInstallation parseInstallation = ParseInstallation.getCurrentInstallation();
parseInstallation.put("GCMSenderId",YOUR_NEW_SENDER_ID);
parseInstallation.saveInBackground();`
This will allow you to track which users are now subscribed with the new GCM Sender ID. It will also tell our Parse importing tools like ours that these subscribed devices can be imported and used.
The open source Parse Server project does not currently support push notifications, but it is in the roadmap and should be available shortly.
If you wish to migrate your Parse Push app to another GCM provider, you will want to update your Android Manifest file with your own GCM Sender Id. Once the app has been deployed to the Google Play store, clients that update to the latest version of your app will register using your GCM Sender Id as well.
You will want to track how many of your active users have updated to the new version of the app to get a better idea of how well your migration is progressing.
The Parse Installation object automatically tracks the client-side app version number. A quick and easy way of determining how many clients have updated your app to the new version of your app is to filter for Installation objects running the new appVersion or newer.
You should, of course, make sure the updated version of your app has registered with GCM using your new Sender Id properly before you release the new version on the Google Play store. The Android Documentation on Cloud Messaging covers best practices for this. If your app has been configured correctly, you should be able to deliver push notifications to the updated clients using your new push notifications provider.
You can find information regarding sending and receiving push notifications from our guide: https://parse.com/docs/android/guide#push-notifications
In particular
...an advanced feature for developers that want to send pushes from multiple push providers, Parse allows you to optionally register your app for pushes with additional GCM sender IDs. To do this, specify the additional GCM sender ID with the following <meta-data> tag as a child of the <application> element in your app's AndroidManifest.xml...
and
GCMSenderId: This field only has meaning for Android ParseInstallations that use the GCM push type. It is reserved for directing Parse to send pushes to this installation with an alternate GCM sender ID. This field should generally not be set unless you are uploading installation data from another push provider. If you set this field, then you must set the GCM API key corresponding to this GCM sender ID in your Parse application's push settings.
Related
I am currently setting up a Firebase Cloud Messaging project. When adding apps to this project some credentials are automatically generated by FCM, e.g. the Server key as well as Android and iOS client keys.
For Android, I can download and use the google-services.json file to setup the client, i.e. registering for an FCM token and receiving push messages. But how do I restrict this so only my app can receive these messages?
I thought it would be the (auto created) Android client API key, so to test I've put an incorrect package name and SHA fingerprint in restrictions for the key. No effect, can still receive messages.
I then tried removing the API key as well as oauth client info completely from the google-services.json file, to confirm that the device then would not be able to receive messages. No effect, can still receive messages. All client info seems to be completely ignored, except for the app id (and the general project info).
So, I am really wondering what prevents reverse engineering of an app to extract the app id and general project info, and then receiving push messages in an entirely different app? I don't understand why the Android client API key, etc. is included in the google-services.json file, or why they are even created, if it is not used.
All the information in google-services.json is essentially configuration data that your app uses to find the Firebase services on Google's servers. You should not rely on knowing it, or lack of knowing it, as a security mechanism.
Instead you should send your messages in a way that ensures they are delivered only to the targeted recipients. A large part of this is sending messages to specific FCM Instance ID tokens. Firebase's Instance ID tokens are unguessable. Initially this registration token is only known on the client-side device where it is generated, and that device determines who to share it with.
By ensuring your client-side code only shares the token with your own server-side code, which then use it to target FCM messages, you can create a completely safe delivery environment where you fully control who can receive each specific message.
On the other side of this are FCM topics, which are a simpler mechanism for delivering messages to groups of users. Since any client can subscribe to any topic that it knows the ID of, topics should be used for delivering messages that require less securely targeted delivery.
I've been in contact with Firebase Support over the past week to shed light on this. It seems there is an important difference between the now deprecated Google Cloud Messaging (GCM) and Firebase Cloud Messaging (FCM), and it is currently not well documented.
With GCM it was possible to use and restrict e.g. the Android client API key with a package name and a SHA fingerprint. This is no longer possible with FCM. The keys are auto created when you add apps to your project in the Firebase console, and included in the google-services.json file, and you can add the restrictions to these under Credentials in APIs & Services, but it will not have any effect.
Please also note that the SHA fingerprint you can add in the Firebase project is only for Firebase Invites or Firebase Dynamic Links.
Be careful and have this in mind when you decide what to use the messaging service for, or when you migrate from GCM to FCM.
There is a feature request for this at Firebase but they currently have no timeline. There also a request now for an update of their documentation regarding this issue.
My android app uses GCM and urbanairship for push notifications.
Now Google has deprecated GCM and is recommending to switch to FCM.
The problem is I don't have access to the Google account which was used to set up GCM as it was set up using one of the developers account who has left. So I can not migrate from GCM to FCM as told in the migration tutorials.
In this scenario, how can I switch to FCM using a different Google account keeping in mind that I use urbanairship?
I want to preserve the registration tokens, or get them replaced without asking customers to uninstall and reinstall the app.
Is it possible that the app registers itself with FCM when I roll down an update?
The problem is I don't have access to the Google account which was used to set up GCM as it was set up using one of the developers account who has left.
This is not an uncommon situation. What I would suggest is contacting Google Support about the GCM Project. It would be best for you to get access to current project, specially if you are the one managing/using it.
After getting access, you could then migrate it to Firebase as needed.
In this scenario, how can I switch to FCM using a different Google account keeping in mind that I use urbanairship?
You can't switch to a different account. However, you could modify your app to receive messages from a different project. I haven't used UrbanAirship before, but AFAIK, if they are using GCM underneath their service, then they too should be handling the FCM migration part.
Is it possible that the app registers itself with FCM when I roll down an update?
In order to register an app is for it to call getToken(). So technically, yes. But you would have to handle pairing/saving the token to it's corresponding user.
With all that said, I would strongly suggest you contact Google Support first.
Here is how I solved the problem:
1. Created a new Google FCM account.
2. Created a new project in Urbanairship console using keys from new Google FCM account.
3. Updated the backend code to send notifications twice - once for old urbanairship project and once for new project. Out of the two attempts, one will fail for sure and one will succeed for sure as customer will be using either of the two versions of the app.
4. Customers using old version of app will have registation tokens which are available with old urbanairship project. Customers using new version of app will have registation tokens which are available with new urbanairship project.
5. When customer updates the app, urbanairship takes care of registering the token with new FCM account server. I don't have to do anything here. This was not expected as token is updated upon fresh installation and not during updates.
So to summarize:
UA Project Old -> Google GCM -> Device with old app version
UA Project New -> Google FCM -> Device with new app version
Here is the FCM Urban Airship migration guide. Assuming you are able to recover your GCM account you only need to follow that guide with your existing sender ID. If you change accounts, you will have to configure the new FCM project API key in the Urban Airship dashboard. The SDK will automatically update all the channels with the new registration token. During the transition period, only devices that have updated will be able to receive push.
I have a self hosted parse-server, when i create a new android user the device token in the database doesn't get set. as a note i am using fcm for push
has anyone got FCM to work with parse server?
I dont think this is possible. Reading from the Pushwoosh website who replaced Parse (since Parse was acquired by Facebook):
GCM Android Push notifications, which are being replaced by FCM now,
require you to create a Project in Google Developer Console and use
your own Sender ID and Server Key. In order to simplify the
configuration process, Parse offered to use their internal Sender ID
and Server Key to send push notifications. If you used the default
Parse Android push configuration settings and didn’t register your own
GCM sender ID and GCM Server key, all your GCM tokens belong to Parse.
This is what we never did at Pushwoosh and we always asked our users
to register their own GCM Sender ID and GCM Server Key. What is
important to understand is that Parse will never share his Private
Server Key as it would compromise all Android push tokens from any
Parse-based project.
What Does It Mean?
It means that you can use the default Sender ID and API key registered
in Parse only to send push notifications via Parse. You can’t migrate
these device tokens to another push service since you don’t have
Parse’s Server Key. In that way these tokens can be considered gone.
The only solution – you should start collecting new push tokens as
soon as you can.
In short you have to use only one.
i actually found a solution.
via https://firebase.google.com/support/guides/parse-android#firebase-notifications
so effectively there is a fix, parse uses the old way of collecting the token via gcm request token method, fcm now auto calls for a token at the time the application first installs. this creates a mismatch hence parse doesn't actually work well with fcm sdk.
but you can actually use them together and although both gcm and fcm get different tokens both these tokens actually point to the same device. i have tested this and it does work well using both tokens from a private parse server.
you must ensure you are using the "ParsePushBroadcastReceiver" or either you use a custom class as the link says. thing is you "FirebaseMessagingService" class and you custom gcm receiver class will both fire when a message comes in. so what i did was receive messages with the FirebaseMessagingService class and filter as required.
If I upgrade my android apps and server notification to FCM, then update it to playstore. Does old apps that not updated (because still use gcm) still get notification? Should I inform all of my user to mandatory update the apps?
Thanks
here is the reply from firebase-support#google.com :
Thanks for reaching out!
Unfortunately, you won't be able to use Firebase APIs to send a notification directly to a target client by using the old GCM registration tokens. Registration tokens are generated by using the combination of Sender ID and API key and if those ID which belongs to GCM is different from FCM project, It will likely throw the MismatchSenderId error (or other error listed in the doc).
Hope this helps.
and the answer is No, FCM can't send push notification to GCM client.
I know that it is possible (Android GCM: same sender id for more application) but I don't know how to make it happen.
GCM is already working properly on our android app. Now we want to use it in our ios app too. But when I try to register ios app for gcm in google developer console, it always registers a new app and provides a new sender id.
NOTE: No plan to use Firebase Cloud Messaging(FCM) yet.
Sender Id and api key have 1 to 1 relationship, so if you wish to use push notification in your ios as well, then, you have to use the same sender id. So you need not to register your app on again.