We have a design approach which is creating a topic for each registered user.
Creating a new user
Save it to our database with a generated token
Subscribe to /topics/{user-token} when user login on android or
ios device.
So if user have more than one device and if we want to send a user specific notification, we just send it to /topics/{user-token} so it received by all devices.
We've not encountered any problem with a few users yet, but is that ok for Firebase limitations and is it a good approach?
(I am moving my comments into an answer)
Most of the times creating an FCM TOPIC per user is NOT a good idea.
Messages sent to an FCM TOPICS are public. Any user (even from a
different app) can subscribe to /topics/{user-name} and receive those
messages.
Example:
Another developer can copy the google-services.json file from your apk.
Then he can subscribe to any topic.
To intercept your user messages the attacker still need to guess the {user-name} or any other identifier you are using. But if you assume this can happen then the issue is big because you would never know if someone is receiving a copy of your messages, and you usually never change {user-name}.
This is not a security issue of FCM. This is part of the topic API design.
If you need secure messages you can send them directly to the device token.
If you still want to do one topic per user, please pay attention to not send sensitive data, or data that should not be intercepted by third parties.
Related
I am working on an app, which requires Android push notifications to be implemented.
I have decided to use Firebase Cloud Messaging directly; without using any other abstraction such as AWS SNS or Pusher.
I would like to avoid storing and managing device tokens in the backend, by using the following approach.
In the android app.
When the user logs into the android application, obtain device token but not send it to the server.
Subscribe to a topic that is based on a agreed convention, such that the topic is unique to that user.
On logout unsubscribe from the topic.
In the Server.
Whenever a situation arises to send a notification to particular user, send push notification to the topic, that is based on the convention.
I would like to know if this is a viable strategy to avoid managing device tokens ?
Case against using topics.
From the official docs.
Based on the publish/subscribe model, FCM topic messaging allows you to send a message to multiple devices that have opted in to a particular topic. You compose topic messages as needed, and FCM handles routing and delivering the message reliably to the right devices.
For example, users of a local weather forecasting app could opt in to a "severe weather alerts" topic and receive notifications of storms threatening specified areas. Users of a sports app could subscribe to automatic updates in live game scores for their favorite teams.
I see that topics are recommended, when multiple devices are to be notified. But I have decided to create a topic per user, this would mean most topics would end up getting subscribed by only one device; Is this approach ok ?
I see that topics are recommended, when multiple devices are to be notified
Yes, multiple devices that have something common to listen to, which is the topic. Topics are used for messages that could be received by the general clients since it is public -- i.e. anyone could subscribe and receive messages sent to it.
What is advised to use for multiple devices, but for the same user is to use Device Groups (see my answer here for tips on Managing Device Groups). However, if you don't mind the "topics being public" part, then your approach should be fine.
Yes, Here required device tokens if we want to send push notification whoever installed your app.
My research we can save device tokens in back end at first time installation of your app that is better according to my understanding so that we can easy to send push notification across all devices.
Let's say I have an Android app with 100 users that I don't know personally. Is it right to make each one of them subscribe to topics like FirebaseMessaging.getInstance().subscribeToTopic("<company_id>_<user_id>"); so I can address them and send notifications for one or two specifically or there is a better way to do that?
If you intend to send a message to specific users only, you could simply go ahead and use to or registration_ids when targeting the specific users. registration_ids has a limit of 1000 tokens per request.
As per the topics, it was designed to easily send messages to its subscribers. Depending on your use-case, it could be fine to subscribe them. However, you should still keep the registration tokens for each user in case you need to send specific messages.
It all depends on your goal.
Anyone can subscribe to a topic, so you should only use those for sending messages targeted-but-public messages. While you can counter this a bit by making the topic names hard to guess, the inherent behavior of topics is that you lose control over precisely what devices are targeted in return for having to write less code.
If you send to a token in your own code, you determine precisely who receives the message. But you will have to run the code that maps the message to the tokens yourself.
I think the answers are pretty clear, I would only like to add that, this method of subscription it can be easily combined with the Firebase web console. If you want to quickly send a message to any topic, the topic is created on registration, so you only have to know the topic name.
In the Firebase Web Console, you can find the target, an application, a token for a device or a topic. If you choose a topic, just write the topic name. There is an error which always says there is no topic, disregard it, and click send, the push will be sent and the subscribers will get their notifications.
I want to build an Android app that allows a user to send notification and data messages to other users. I've started using Firebase only recently, and Firebase Cloud Messaging is still pretty confusing to me.
I have already implemented sending a message to a specific device using the Firebase Instance Id. However, in my app, a user can log out and log into their accounts using different devices, so this isn't really what I want. I read the documentation and it's pretty confusing, they mention sending messages to user groups, and topics (which only apps can subscribe to, not users).
Is there a way to send a push notification directly to another user or a group of users using only their UIDs? If not, is there any other way I can implement this?
I did it storing the FCM Token in a device structure by user. When the user login, add the deviceData to the userToken structure. You need clear deviceData when the user logout. This way, you will only send notifications to logged devices.
Ex (This is not like mine structure, but it can help you to wondering a good way to do this):
-userToken
-idUser1
-device
-idDevice1
-fcmToken: "xxxxx"
-idDevice2
-fcmToken: "YYYYY"
Hope that I helped you
Alright, so to make sure this works across multiple devices when a user logs in, I just make the device subscribe to a topic with the name equal to the user's UID. Now if I want to send a notification to a user, I just send an FCM message on the topic with the name equal to the user's UID!
Example: If my UID is equal to "asdf", whenever I login using multiple devices, each of the devices automatically subscribes to the topic with name "asdf". So now, if I send an FCM from the server on this topic, all the devices from which I am logged on to obtain this notification.
I am new to gcm api for android and have for some time now i have being working on an android app to allow chatting between two users of the app. The app is such that a chat can only be initiated when one user opts to contact the other user. But my confusion comes in the manner i would be able to create a chatroom for these two users and for the other user to be able receive messages. since i found out that each user must subscribe to a topic inorder to receive messages in that topic. Would i have to subscribe all users to all possible topics or what? that is my big question but it seems it would have so much overhead considering i have 1000+ users.
Please i need all the help i can get here. Thanks
Would i have to subscribe all users to all possible topics or what?
GCM topic messaging allows your app server to send a message to multiple devices that have opted in to a particular topic.
It is not a requirement but it can ease the work for the server to send messages. In this tutorial, you will see that they have created a chat like environment using GCM without using the topic function.
BUT consider the effects on your server like how will it behave on the potential load when you use the topic messaging, especially the the message will trigger an interaction from the user to the server.
I have an app that runs across iOS and Android. I'm working to add push notifications to that app.
At a very high level, devices register with the Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM) and receive a token. They then hand that token back to the server that's in charge of sending notifications. That server, when it wants to, sends a notification to APNS or GCM and says "send this notification to the devices with these tokens".
So, my apps need to be able to securely send their tokens to my server, and delete those tokens from the server when the user no longer wants to receive notifications. It's very easy to add a simple CRUD page on the server side which handles ?create=<token>, ?delete=<token>, etc.
But what happens when someone goes to my server and starts spamming random values for ?delete=<token> — it seems like they'd be able to just delete random device tokens at will?
I've thought about the "delete" case a bit more, and I think it should be easy: the app can just send along a generated public decryption key with the initial “create this token” request. That key can be stored against the token. When the app wants to delete, it can send along the encrypted copy of the token, and the server can match the token against the decrypted copy, verifying that the app must possess the stored public keys matching private encryption key (which is a secret known only to the app).
What happens when someone starts spamming random values for ?create=<token> — do they get to just fill up my database table with fake device tokens?
I can't see an easy answer — rate limiting "create" requests from any single IP address seems to be about the best we can do without registration involved. That obviously isn't going to help us against any distributed attack.
Ideally I'd like to enable push notifications by default / without the user having to "register" or anything like that. My first thought is that each device token should be tied to a known canonical Apple ID or Google account — but how do I stop users from falsifying those? Do devices come with a certificate that I can get an authoritative public key for (in which case each device can just get a row tied to its public key)? What's the best way for me to implement authentication here?
The solution to the problem for android can be found Here. In brief it can be summarised as
You use the GoogleAuthUtil class, available through Google Play
services, to retrieve a string called an “ID Token”. You send the
token to your back end and your back end can use it to quickly and
cheaply verify which app sent it and who was using the app.
A lot of good questions here. :)
Let me try to break it down.
General thoughts
I don't think it's good idea to mix Android and iOS here. High level push notification architecture is similar between them, but that's about it.
Tokens are long (as I remember iOS token is uuid). So, there is no way to guess it by just randomly trying different values. So, I would say ?delete=<token> case is non existent.
The case of ?create=<token> is more realistic. First of all, somebody can bring your server to knees, registering millions of tokens. Also, if you are sending some sensitive information via push notification, you may don't want it to be received by non authorized app users.
Android solution
For Android it's easier.
As soon as you get a token on the server, just send a push message with some randomly generated string (store it in DB). Your application on a device will get this string and will send it with the token to the server (via second web call). And your server make sure that it will send anything to this token only after it was authenticated.
This way you rely on GCM ability to deliver messages to correct clients to make sure that authentication information (random string) is delivered to your application.
iOS solution
The problem with iOS is that push notification doesn't automatically trigger code execution, if the application is suspended or in background.
So, if you will try to do the same thing and a user accidentally exits your app, while push notification is being deliver than your app will never see it.
You can do following (the idea is basically the same as for Android, only with difference that we may need to require user interaction)
Push notification with a message "Please run my app and enter X" (where X is some random string)
This way, if your app is in background, a user will click on this message, enter X and your app will authenticated to the server.
In the case, if app is in foreground, it will get push payload and can authenticate directly.