Description
What feature would you like to see?
Previously, Cloud Messaging project supported the use of multiple app servers configured with different Firebase projects according to documentation (where this documentation is silently removed in October 2022 after the functionality was actually removed 1.5 year earlier at firebase-messaging:22.0.0).
Receiving messages from multiple senders
FCM allows multiple parties to send messages to the same client app. For example, suppose the client app is an article aggregator with multiple contributors, and each of them should be able to send a message when they publish a new article. This message might contain a URL so that the client app can download the article. Instead of having to centralize all sending activity in one location, FCM gives you the ability to let each of these contributors send its own messages.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:
Swift — token(completion:)
Android — FirebaseMessaging.getInstance().getToken()Make sure that you do not add multiple sender IDs to a single token request, as this can have unpredictable results. Make each call separately, once per sender ID.
Finally, share the registration token with the corresponding senders, and they'll be able to send messages to the client app using their own authentication keys.
Note that there is limit of 100 multiple senders.
However, senderId cannot be passed to FirebaseMessaging.getInstance().getToken().
Furthermore, firebase-iid dependency is removed in firebase-messaging:22:0.0. According to the changelog:
Caution: This is a breaking change for apps that use FCM and the deprecated Firebase Instance ID API to manage registration tokens.
We strongly recommend migrating to FCM's token APIs. If you're unable to migrate to the replacement APIs, add a direct dependency on the firebase-iid library to your build.gradle file.
We defined firebase-iid
as a dependency to continue using the deprecated FirebaseInstanceId.getInstance().getToken(senderId, scope) as suggested in the release notes.
This seems to work for retrieving tokens for multiple senders; however, when tokens are refreshed;
- FirebaseInstanceIdService.onTokenRefresh() is not getting called for any senders (tested with firebase-messaging:23.1.0 and firebase-iid:21.1.0). This is contrary to what the javadoc says:
This method will be invoked on token changes even if onNewToken is also used.
- FirebaseMessagingService.onNewToken(token) is only getting called for the sender of the default project. It is not getting called for other senders.
Because token refresh callbacks don't work and the deprecation due to migration from Firebase Instance ID to Firebase Installations ID, this doesn't seem to be a viable option.
The second option is to initialize FirebaseMessaging
using another FirebaseApp
initialized with FirebaseOptions
object for each other sender. But, there are multiple problems with this approach:
- FirebaseMessaging.getInstance(FirebaseApp) is package-protected.
- FirebaseApp.get(class) is marked with @KeepForSdk annotation.
- Even if we used
FirebaseApp.get(class)
; we have to pass ProjectName, ApplicationId, ApiKey toFirebaseOptions
which are not known by us since the Firebase Projects for other senders are owned by other parties. Further, getting ApplicationId and ApiKey requires these third parties to set a new Android App in their Firebase Project for each of their consumers (Although our tests show that token retrieval and FCM messaging still works with our tester app using the ApplicationId and ApiKey belonging to a different package name!). - FirebaseMessagingService.onNewToken(token) is only getting called for the sender of the default project. It is not getting called for other senders.
These were mentioned in different tickets (#3987, #3205, #2778, #2285, #4053) and official responses of the contributors of this project are contradictory (#3987 (comment), #2778 (comment))
We would like to get clarity on the support for multiple senders feature.
We need this feature to be recovered; otherwise we would be stuck at firebase-messaging:17.0.0.
If this is not possible, we would like to get a migration guide since we are already live for 4 years with our multiple sender setup based on the removed docs since this would involve multiple parties to collaborate and make modifications in their apps.
How would you use it?
Preferably, we would like to;
- have FirebaseMessaging.getInstance().getToken() API to be changed to FirebaseMessaging.getInstance().getToken(senderId)
- have FirebaseMessagingService.onNewToken(token) API to be changed to FirebaseMessagingService.onNewToken(token, senderId) and have it called for all sender IDs, not just the default one.
Our use case for multiple senders which is already live for 4 years is as below:
We have 3 senders for our app;
- one owned by MasterCard (for MDES system) for mobile card tokenizations
- one owned by a third party company used with their Android SDK and their App Server
- one owned by our own App Server for other features of our app
Removal of this feature and migration to single sender ID have huge implications for our company and our partners;
- we would have to share our private Web API Key of our App Server with other companies which is not acceptable from security perspective. Those other companies would use this API Key to send messages to our app. So, for example, MasterCard would need to get the private API Keys of the apps of ALL of their consumers. Each company would have to share their private API Key with MasterCard so that MDES can send FCM messages. But it would mean that they can send any FCM message, leaving us no way to verify if this FCM message is sent by our own App Server or MasterCard, therefore the security issue.
- we would have to migrate every customer to use single token for single server. Since there is no guarantee that customer will launch our app immediately after update (and have connectivity to the internet); customers may not receive important FCM messages until each one are migrated.
- both us and our partners have to make changes in their servers and their SDKs.
Therefore, we prefer to have the functionality to be recovered; otherwise a clear migration guide for us and our partners.