The only change that the GCM -> FCM migration doc requires is changing the endpoint:
Update your server code to use new FCM endpoints for sending messages via HTTP and XMPP... Optionally, you may want to evaluate the FCM HTTP v1 API, which offers an improved security model and new capabilities for customizing messages across
But the video seems to tell a different story:
I'll need to update to a new more secure server key which I can get from the firebase console... download the service account credentials then I'll drag the JSON file into my project... replace the GCM API key with this service account key I'll update my HTTP header to use this access token...
Can we continue to use the GCM server api key when sending requests to the new FCM endpoint or do we "need to update to a more secure server key" obtained from the FCM console?
The GCM documentation you pointed out is kinda (not that much) old. It shows what needs to change when migrating from GCM to FCM Legacy. What Jen Person showed in the video is when you are to use FCM v1 (see the uri on 8:19).
Can we continue to use the GCM server api key when sending requests to the new FCM endpoint or do we "need to update to a more secure server key" obtained from the FCM console?
From my comment here (with minor updates):
Depending on which type of GCM API Key you were using (if this is a reeeaally old project, you might still be using a different type of Key), it may not work. Regardless, after you import your GCM project to Firebase, it would probably generate the necessary API Keys (Server Key for this matter) that you could (and should) use in order for FCM to work.
Related
I had used fcm to send notification in my app using api.after some days google send this and removed my app from play store.please help me.
I have tried everywhere not getting exact answer.
Put FCM Key in untrusted environment is a security issue, Any hackers are possible to send message to any user by using FCM key.
FCM key shouldn't exists in your public app like downloaded to your instance, Store in local storage, Hardcode inside application etc.
FCM key should only exists in trusted environment like your server, cloud functions etc.
You can also see this Do I need to protect my firebase Server Key?.
There are a lot of confusing answers on the web, hope someone can make it clear, I have an app that uses GCM.
The GCM to FCM FAQ states that:
Your GCM and FCM registration tokens are mutually interchangeable
Note that client SDKs and GCM tokens will continue to work indefinitely.
It is already very clear that the old GCM token is still valid after GCM service deprecation.
However it is not clear if new installation of my GCM app will still be able to generate new GCM token.
"client SDKs will continue to work indefinitely", does it only mean the notification receiving part will continue to work, or the generate new token part will continue to work too?
Any clarification from official Googlers are welcomed, thank you
What I understood from Frank's answer, the existing tokens from GCM will continue to work but new installations of your app which uses GCM may not generate tokens anymore.
But from mid-April:
You won't be able to compile code using the old client-side APIs on
a newer SDK/Google Play Services anymore
You won't be able to call the GCM REST API to send messages anymore
New installations of your existing GCM-using app may not be able to
get a token.
I also found this thread, according to Diego:
Both GCM sdk and FCM sdk use Google Play services to create tokens and
receive messages. Google Play services is not being deprecated. GCM
sdk is being deprecated in favor of the FCM sdk. In this context
deprecated means:
already released versions of the GCM sdk will keep working
GCM sdk will not receive updates, bugfixes or support
if future versions of Android will introduce breaking changes, the GCM sdk will NOT receive the necessary updates and therefore will not
work on the new devices.
On the Server side, the GCM endpoint is being deprecated in favor of
the FCM endpoint.
the FCM endpoint supports GCM token
we plan to disable the GCM endpoint in the future
Google is deprecating Google Cloud messaging in favor of Firebase Cloud Messaging:
Firebase Cloud Messaging (FCM) is the new version of GCM. It inherits
the reliable and scalable GCM infrastructure, plus new features! See
the FAQ to learn more. If you are integrating messaging in a new app,
start with FCM. GCM users are strongly recommended to upgrade to FCM,
in order to benefit from new FCM features today and in the future.
From some tests I made on my servers, the FCM URL (https://fcm.googleapis.com/fcm/send) works with GCM projects, and vice-versa - the GCM URL (https://android.googleapis.com/gcm/send) works with FCM projects.
Migrating all existing GCM push sending code to FCM would save a lot of trouble and refactoring (I will not have to check, for each push, whether the app version is FCM or GCM).
Is this backward and forward compatibility officially supported or documented?
If you refer to #IanBarber's answer here:
The tokens are different. Firebase Cloud Messaging (GCM) use gets registration tokens from the Instance ID API which means you'll get different tokens between that and GCM2.
You'll need to send that new token back to your server to send messages. On the server side the APIs should be fully compatible (just new endpoints for FCM).
However, if you're looking for any official documentation, I don't think there is one that explicitly states it. Since as much as possible, Google encourages the use of the corresponding APIs, endpoints, etc. depending on what you really intend to use.
I am using the Pubnub library (Pubnub-CodeNameOne-3.7.8.cn1lib) in my social app project (which includes a real-time chat that I implemented with your great tutorial: https://www.codenameone.com/blog/building-a-chat-app-with-codename-one-part-5.html).
But since Apple will no longer accept http URL connections from applications, I had to reinforce the security of my app, and so I decided to use HTTPS and activate the Access Manager feature in Pubnub dashboard (I followed the Pubnub tutorial https://www.pubnub.com/docs/codenameone-java/pam-security#understanding_access_manager_permissions_hierarchy).
So I changed the instantiation of Pubnub in my CN1 project like :
pb = new Pubnub(PUBNUB_PUB_KEY, PUBNUB_SUB_KEY, SECRET_KEY, true);//enable SSL
pb.setAuthKey(USER_UIID);
Unfortunately I still get an error when I subscribe/publish through Pubnub:
[Error 112-0] : Authentication Failure. Incorrect Authentication Key :
{"message":"Forbidden","payload":{"channels":["myChannelID"]},"error":true,"service":"Access
Manager","status":403}
Therefore, I would like to perform administrative PAM functions, such as granting or revoking, in order to solve the above error message problem.
But I don’t find the pubnub.pamGrant(), or pubnub.pamRevoke() methods which are mentioned in the Pubnub tutorial. So I am still stuck on this error.
Have you an idea about how I can resolve this? Thank you very much for your help.
PubNub Access Manager & SSL/TLS
While you should be using Access Manager to secure your channels on a per device/user basis, Access Manager is not required in order to use PubNub over TLS (SSL is the deprecated/vulnerable predecessor and often these terms are used interchangeably).
So your initialization code is correct to enable TLS (https connections) when PubNub operations are invoked.
pb = new Pubnub(PUBNUB_PUB_KEY, PUBNUB_SUB_KEY, SECRET_KEY, true);
But if you enable Access Manager on your key set (pub/sub keys), then you are required to grant permissions (read, write & manage) for channels on auth-keys. Each end user should have a unique auth-key that has the permissions for the channels that are required for that user to publish, subscribe, get history, presence, etc.
You grant permissions from your secure server which you initialize PubNub with the publish, subscribe and secret keys (secret key is required to execute the grant API). With v4 PubNub SDKs, the server has super admin permissions when it inits with the secret key. v3 SDKs require the server to grant itself access to its own auth-key but since Codename One is for mobile client apps, you don't need to wait for a v4 PubNub SDK for Codename One. And I would assume you would be using Java on your server and our v4 Java SDK v4 has the super admin permissions feature when initialized with the secret key. NOTE: the docs need to be updated as they still state that an auth-key is required even when secret key is used to init.
So my recommendation is, enable SSL (TLS) as you are already doing for your server and clients but disable Access Manager for the short term. Once you have your base functionality working, integrate the use of Access Manager and auth-keys into your server and clients.
Google is deprecating Google Cloud messaging in favor of Firebase Cloud Messaging:
Firebase Cloud Messaging (FCM) is the new version of GCM. It inherits
the reliable and scalable GCM infrastructure, plus new features! See
the FAQ to learn more. If you are integrating messaging in a new app,
start with FCM. GCM users are strongly recommended to upgrade to FCM,
in order to benefit from new FCM features today and in the future.
From some tests I made on my servers, the FCM URL (https://fcm.googleapis.com/fcm/send) works with GCM projects, and vice-versa - the GCM URL (https://android.googleapis.com/gcm/send) works with FCM projects.
Migrating all existing GCM push sending code to FCM would save a lot of trouble and refactoring (I will not have to check, for each push, whether the app version is FCM or GCM).
Is this backward and forward compatibility officially supported or documented?
If you refer to #IanBarber's answer here:
The tokens are different. Firebase Cloud Messaging (GCM) use gets registration tokens from the Instance ID API which means you'll get different tokens between that and GCM2.
You'll need to send that new token back to your server to send messages. On the server side the APIs should be fully compatible (just new endpoints for FCM).
However, if you're looking for any official documentation, I don't think there is one that explicitly states it. Since as much as possible, Google encourages the use of the corresponding APIs, endpoints, etc. depending on what you really intend to use.