For a startup considering making public notifications intended for website users available via a Pusher channel, how do you prevent people from subscribing to that channel for a long period of time (camping essentially)? I know you can disconnect users after a period of inactivity if they are connected from a web client (by checking for activity on the client and sending a disconnect after a period of inactivity), but what if users decide to connect via a command-line app or something similar?
Pusher provides private channels where the subscription to those channels need to be signed using your application secret in order for the subscription to be allowed.
Given the command-line app example you've provided the author of that application would not know the application secret and would therefore not be able to subscribe to the private channel.
Related
I want to send FCM to everyone who installed the app. Is it essential to get everyone's tokens from the database every time?
My app is using firebase firestore overall. If there are 100,000 users,
do I have to read 100,000 from database to send fcm each time? (I think it`s little heavy stuff isn`t it?)
another workroad exists?
I wonder Is the only way to send it by putting it in the registration ID?
And can you send it on time? All apps on the market send push messages on time, but if you read 100,000 and send fcm separately, shouldn't it arrive like this at 9:01 or 9:02? But why do I always get messages at 9 o'clock?
What are the methods, logic, algorithms they use (the way companies usually use)
I still have no clue at all.
There is no "send to all users" operation in FCM. You either will have to send to each token (that's not a heave operation for FCM, which handles billions of such calls every second), or you have to subscribe all instances to a specific topic and then send to that topics (which ends up the same behind the scenes, just with Firebase loading the tokens for the topic for you).
This has been covered a few times before, so I recommend checking:
How do you send a Firebase Notification to all devices via CURL?
How to send notifications to all devices using Firebase Cloud Messaging
Firebase Cloud Messaging - Send message to all users
The notifications panel in the Firebase console has an option to deliver messages at a specific time, but no such option exists in the Firebase Cloud Messaging API. You'll have to either implement your own mechanism to schedule the delivery, or you can deliver a data message right away and then only display the notification on the device when it's time.
This also has been covered a few times before, so check:
Firebase Messaging FCM Distribution over configurable time interval
How can scheduled Firebase Cloud Messaging notifications be made outside of the Firebase Console?
Flutter Firebase Messaging: How to send push notifications to users at specified time
I'm trying to piece together the general workflow of giving a user push notifications via the service worker.
I have followed this Google Developers service worker push notifications tutorial and am currently thinking about how I can implement this sort of thing in a small user based web app for experimentation.
In my mind, the general workflow of an web app supporting push notifications is as follows:
Client visits app
Service worker yields a push notification endpoint
Client sends the endpoint to the server
Server associates the endpoint with the current user that the endpoint was generated for
Every time something that your app would say is notification worthy happens, the server grabs the push notification endpoint(s) associated with the user, and hits it to send a push notification to any user devices (possibly with a data payload in Chrome 50+, etc)
Basically I just want to confirm that my general implementation thoughts with this technology are accurate, else get feedback if I am missing something.
You are pretty much bang on, there are some specifics that aren't quite right (but this is largely phrasing and may be done to personally taste).
Client visits app
Register a Service Worker that you want to use for push messaging
Use the service worker registration to subscribe the user to push messaging, at which point the user agent will configure an endpoint + additional values for encrypting payloads (If the the user agent supports it).
Client sends the endpoint to the server
Server store the the endpoint and data for later use (The server can associate the endpoint with the current user if the server if the web app has user accounts).
When ever the server wishes to send a notification to a user(s), it grabs the appropriate endpoints and calls them that will wake up the service worker which can then display a notification.
Payload support in coming in Chrome 50+ and at the time of writing payload is support in Firefox, but there are 3 different versions of encryption used for the payloads in 3 different versions of Firefox, so I'd wait for the payload support story to be ironed out a little before using it / relying on it.
Is there a way to make the client have only read-only permissions to channels since we are distributing the client key with the web app using the pusher.js sdk?
The application key itself does not determine the permissions of a client. It only identifies which application the client is connecting to.
By default all subscriptions are read-only. Pusher offers three channel types:
Public
Private - with a private- name prefix that also requires subscription authentication
Presence - with a presence- prefix that also require subscription authentication and additional functionality for adding functionality to show which users are subscribed to that channel
A above, in order to subscribe to either Private or Presence channels your server needs to authentication the subscription request.
If you actually want a client to be able to trigger events on channels you need to:
Enable client events for an application
Subscribe to, and be authenticated for, a private or presence channel: channel = pusher.subscribe('private-channel')
Once subscribed (check using the pusher:subscription_succeeded callback) call channel.trigger('client-event', eventData) being sure to prefix the event name with client-
When using the PubNub Presence feature, is it possible to provide a HTTP callback that PubNub calls when a user joins or leaves a channel? In my case I want to call a Parse.com cloud function.
To clarify: I don't want to call the function from a client, but have the PubNub.com servers take care of it.
Calling a web service on PubNub Presence events
PubNub offers Presence "HTTP Callback" generated from PubNub.com servers. You must ask your Account Manager to enable for you; send an email to support#pubnub.com to enable. Ask for "Presence Callback Active" and "Presence Callback Inactive" settings. You'll want to setup a dev/prod key pair to point the WebHook URLs at different environments.
The HTTP callback URL that is triggered when a channel becomes active.
Webhooks are now supported for all presence events: join, leave, timeout and state-change, as well as the channel active and inactive events.
For a full explanation please read this StackOverflow about PubNub Presence Webhooks and how to get them configured for you keys.
Now I'm using PushSharp library to send Apple push notifications (through APNS), but I want to migrate to Notification Hubs for robustness and scalability.
I'm planning to implement sending notification via Azure Notification Hubs using backend registration as described in this article. So:
There is a method of backend API that an iOS client calls when it has push token updated. In this method I do the registration tagging it with user id. (Previously, I stored push token to user link in DB.)
When I have some notification to send for a specific user I send it using the tag (user id). (Previously, I used APNS device token from DB.)
It seems like a working solution, but in Notification Hubs documentation it's said:
It is important to note that registrations are transient. Similar to the PNS handles that they contain, registrations expire. You can set the time to live for a registration on the Notification Hub, up to a maximum of 90 days. This limit means that they must be periodically refreshed, and also that they should not be the only store for important information. This automatic expiration also simplifies cleanup when your mobile application is uninstalled.
And that is the problem. Sometimes I need to send notification to devices that haven't updated the token for 90 days and so forth the registration. So the APNS token will still be active, but Notification Hub's registration will be invalidated. So I just lose the communication channel for the user.
How do you handle this?
Of course, I can still store tokens in DB and make a job that updates registrations periodically. But that's not what you expect from a push notification solution like Notification Hubs.
You can either refresh your registrations from the application or from your server. If you do it from your application, the app must be launched by the user in order for the registration to be refreshed.
Therefore, if you require that device registrations remain active even for apps that weren't launched for over 90 days, you have to refresh the registration via your server, and running a job in your server that would refresh the tokens seems like your only option.
I agree that Notification Hubs' decision to expire the tokens seems strange. Perhaps they had in mind the behavior of MPNS (Microsoft Push Notification Service) notification channels, which expire more often than APNS device tokens or GCM registration IDs.
Just a quick note, since the answer is 2 years old. In this blogpost Azure states:
It is important to note that registrations and installations by default no longer expire.
I assume that this makes the expire field confusing, but not a problem anymore.
UPDATE
Older notification hubs still have this issue. You need to update them to set the expiry to infinity, instructions are found in this forum post. New hubs are automatically set to infinity.
As per latest notification hub documentation, this 90 days limit has increased to lifetime, which means you don't need to re register device after 90 days.