On this page they explain Web Push with Service Workers stating
Chrome currently uses Firebase Cloud Messaging (FCM) as its push service. FCM recently adopted the Web Push protocol. and then explaining Firebase and so on...
Since the Service Worker gives me a unique endpoint and a pubkey, it seems to me that technically it should be possible to use that endpoint directly, without anything additionally - except if Google deliberally forces a registration.
I mean, just send a POST request to that endpoint, sending just the notification data encrypted/authenticated using the pubkey without any "VAPID".
Do I absolutely need a Firebase account or is it possible to access the endpoint directly (without additional registration) if I just want to send a notification to a single device?
It's 2021 and all major browsers implement a push service and support VAPID now. You use a web push library (Javascript, Python, C#,..) of choice.
There is no need to register anywhere.
The technical mechanism in short is this:
You generate two VAPID keys once using the push library. One key is private and one is public.
The public key is used in the javascript as "application server key" when subscribing to the push service of the browser.
If the subscription is successful you receive a subscription object from the browser containing an endpoint and two additional keys.
The endpoint is an address depending on the web browser / manufacturer and the service it is currently using. The endpoints look like (Oct 2021) e.g.
Google Chrome h_tt_ps://fcm.googleapis.com/fcm/send/cz9gl....., Microsoft Edge h_tt_ps://wns2-par02p.notify.windows.com/w/?toke....., Mozilla Firefox h_tt_ps://updates.push.services.mozilla.com/wpush/v2/gAAAAABhaUA....
If your server program has this information (endpoint and keys from subscription object) it can send a push message to the endpoint with the push library. The corresponding service in the web, hosted by the manufacturer sends this to the browser's service on the device.
There is the PushAPI which shall get used.
But it doesn't is supported by every Browser at the moment.
You can find nice examples in the Service Worker Cookbook of Mozilla
Related
When using service workers to send push notifications to a user device from the Edge browser, does Edge use an Azure service as the push service to relay the message payload to the client?
I am interested in using push notifications inside a closed environment and confused on the security concerns I may need to be aware of.
Resources: Push Service Fundamentals
From the doc you provide, it says
Each browser can use any push service they want, it's something developers have no control over. This isn't a problem because every push service expects the same API call. Meaning you don't have to care who the push service is. You just need to make sure that your API call is valid.
So I think you don't need to care about the push services browsers using and don't need to worry about the security concerns.
But to answer your question: For the push service Edge using, I think it's Windows Push Notification Service (WNS). For other browsers, you can also refer to this article.
Is push support in Service Workers dependant on Firebase (and Apple's equivalent)? All the tutorials I find have a step where you register a Firebase account, but for our webapp this is a no-go as it will be used at premises without internet access.
I would have assumed that it was possible to register a URL that conformed to some protocol that the OS would register with, but I cannot find any information of the sort.
If it is the case that one needs internet access for service worker push support I assume the only option for a web app to receive background notifications is to wrap it in a native web view and use that to call out to on-premise services.
Internet or third-party push services are not required if you provide a local push service on a local network server that can be accessed via HTTPS URL from clients' browsers. Your local push service needs to implement the W3C Push API specification, and you could also search the web or GitHub for an open-source push service in the language of your choice.
The browsers would would require an HTTPS URL that resolves to a server on your network via hostname or IP, so self-signed SSL certificates would most likely be used. The devices would need the certificates (or CAs) implicitly trusted or explicitly added as a trusted CA/cert.
tldr; it depends on your browser, as it needs to be configured on a per-browser level. As of May 2018, it seems as if Firefox is the only one that lets you configure the service url. For everyone else, you need internet for push messages to be delivered.
The December 2017 Push API specification (which is the official one as of May 2018), says this:
The term push service refers to a system that allows application servers to send push messages to a webapp. A push service serves the push endpoint or endpoints for the push subscriptions it serves.
There is only one push service per user agent and it cannot be changed from the default value. This limitation is due to a variety of performance-related concerns, including the complexity of running reliable push services and the impact on battery lifetime if there were an unbounded set of push services to which a device could connect.
In April 2018 they relaxed this requirement and the spec now allows for configuring a different provider.
I also recommend reading this the dumbed-down version of how webpush works, where the main points are as follows:
First the end user's web browser needs to establish a push channel with the browser manufacturer's push server. In the case of Firefox, this would be a Mozilla server, in Chrome's case, this would be a Google server. After this is done, a unique endpoint URL is sent to the browser, and the browser generates a public and private key pair which is stored internally in the browser. The browser then makes a public key and a user authentication secret used by your server to E2E encrypt messages to the user's browser.
The browser sends the public key, authentication secret and endpoint URL to your server, and the server stores this somehow (in a database, in memory, a file, whatever).
When the time comes that the server wishes to send a push message, it retrieves the stored information on the push message subscription and creates an encrypted message with the public key and user authentication. Then the server contacts the endpoint URL and tells it to push some content to the user agent.
Given everything looks OK, the push server pushes the message to the user's browser.
Our goal is sending notifications to groups of devices from our backend, and only from server side is possible to know which device should receive the notification.
We've done some attempts with AppCenter because we mostly work with Xamarin iOS/Android/Forms, but now we have the doubt that it's probably better to use directly Firebase API because wider and more powerful.
I see that with new version of API (HTTP V1) is not possible to send a notification to a list of tokens, feature that was available in legacy API using registration_ids parameter (https://firebase.google.com/docs/cloud-messaging/send-message).
Device group name (legacy protocols only)
I cannot use topics because when it's time to send the communication is a server's responsibility to prepare the "mailing list" for notifications.
I was thinking to use device group messaging (https://firebase.google.com/docs/cloud-messaging/android/device-group) but these are part of the legacy api, and I'm not sure if it makes sense/it's possible to use them with new version of API.
Is an option to send a batch of 100-200-500 push notifications each one to only one token? In theory there isn't a limit to notifications which is possible to send, but I'm worried that sending too many of them I could risk to be banned.
Is it better to use legacy API? Also AppCenter (Microsoft) uses legacy API, it's evident because of how the setup works and because from AppCenter's console it's possible to send notifications to a list of tokens, feature unavailable on Firebase's console.
Another person just asked something similar but the answer was to use topics (How to send firebase notification for all user at a time?).
Got here from the link in your comment in my answer here. And just to reiterate my response there, when sending messages to multiple tokens with v1, the suggested approach now is to use Topics Messaging, since registration_ids is not supported.
Is it better to use legacy API?
v1 was described as the more secure, cross platform, future proof way of sending messages to FCM clients. More secure since it uses OAuth2 security model.
However, if your use-case is better with using the legacy API, then I suggest you go ahead with using it.
This page suggests that you should stay with the legacy API if you want to continue to use the multicast feature: https://firebase.google.com/docs/cloud-messaging/migrate-v1
Any apps that use device group messaging or multicast messaging, however, may prefer to wait for future versions of the API. HTTP v1 does not support these features of the legacy API.
Everyone who successfully authenticates through Google account would be able to execute the API through the API Explorer.
I would like to limit the ability to execute the API through API Explorer only to some users. But at the same time have the API accessible for all users of my Android and iOS apps.
Security in the case of at least Android App is facilitated through the Android Client Id and SHA fingerprint. So, the scope here is to NOT include the App access security.
Identify that the request is coming through the API explorer. One way is through the origin/referrer in the headers. For obtaining header information see this question.
And,
If the list of users is known, in the endpoints method raise endpoints.UnauthorizedException if the user (endpoints.get_current_user()) is not in the list.
Python sample code:
if self.request_state.headers.get('x-referer') == "https://apis-explorer.appspot.com" and endpoints.get_current_user() not in MY_LIST:
raise endpoints.UnauthorizedException('Not Authorized')
I've been using ASP.NET and PushSharp to send push notifications to my iOS app clients with the simple following code (after certificate configurations etc):
//ASP.NET + PushSharp
AppleNotification notification = new AppleNotification(PushToken).WithAlert(message);
broker.QueueNotification<AppleNotification>(notification);
This worked perfectly on isolated hosts running classic IIS/ASP.NET but now I'm moving towards Windows Azure. When I try this code on Windows Azure, notifications sometimes fail to send, and restarting the website (Standard mode) helps. However, since this is an unreliable approach I've decided to move to Azure's Notification Hub service. I've created the hub, uploaded my certificates, started coding but I couldn't find the equivalent of my previous code. I don't need to broadcast messages to all users, I need to send a push notification to a single device, given that I have the push token. I've looked at Windows Azure ServiceBus Push Notifications APNS Architecture but the link provided at the answer is extremely confusing and I couldn't understand it. How can I, simply push a message to a push token on Windows Azure? Do I have to use notification hub? (I don't use a VM) Any simple approach is welcome, pure ASP.NET/PushSharp-based approach is preferred as I don't need to change my whole codebase.
I'm not sure what kind of object a PushToken is. The way Notification Hubs work is, rather than providing a one-to-one messaging model (where you must identify each and every recipient of the message, whether that is by channel, device token, or registration ID), it provides a tag-based model. However, this does not mean that tags can't be unique to individual users, and in fact you can used just about any token as a tag.
This is a new model, unlike Azure Mobile Services or direct use of APNS, so it's not likely to be directly portable from your existing code. But, in my opinion, the Notification Hubs model is simple once you understand tags. It supports native payloads (constructed by the server that is sending the notifications) and template payloads (where the template is constructed by the receiving device and provided to Notification Hubs at registration time, and then parameters in the template are supplied by the server when it sends the notifications to the templates).