On Mozilla's PushSubscription.endpoint page, they have listed all browser compatibilities.
However, they do not state which Push Services are being used by each one of them. I figured, I might as well download each browser and test them all out by subscribing through PushManager.subscribe().
Now, I'm just wondering which one is needed for Safari v16 and higher?
You think also configure these endpoints as CORS endpoints which are allowed to send notifications to one of your App Services for example, which can be convenient.
Complete list of Push Services are down below:
Chrome (v42 or higher): https://fcm.googleapis.com
Edge (v17 or higher): https://wns2-am3p.notify.windows.com
Firefox (v44 or higher): https://updates.push.services.mozilla.com
Opera (v29 or higher): https://fcm.googleapis.com
Safari (v16 or higher): ?
Chrome Android (v42 or higher): https://fcm.googleapis.com
Firefox for Android (v48 or higher): https://fcm.googleapis.com
Opera Android (v29 or higher): https://fcm.googleapis.com
Safari on iOS: NOT SUPPORTED
Samsung Internet (v4.0 or higher): https://fcm.googleapis.com
WebView Android: NOT SUPPORTED
Please let me know, in case you know which Push Service is being used for Safari v16 or higher. Thank you.
UPDATE: January 16, 2023 9:54 PM
According to the following GitHub repository List of all known push services, the following list can be used:
android.googleapis.com
fcm.googleapis.com
updates.push.services.mozilla.com
updates-autopush.stage.mozaws.net
updates-autopush.dev.mozaws.net
*.notify.windows.com
*.push.apple.com
Thanks to #collimarco.
You can see a list of all known push services here:
https://github.com/pushpad/known-push-services
The list of push service hosts is complete and covers all major browsers (Chrome, Firefox, Opera, Edge, Safari, etc.). We use that list for limiting outgoing connections to trusted hosts.
For example for Safari the host is *.push.apple.com.
Related
Under the assumption that the user uses an up to date standard browser (eg. FF, Chrome, Edge, Safari, Opera), doesn't have any extensions in his browser, not effected by viruses, etc.: can you by javascript modify standard Request Headers; eg. Referer, Host etc.?
(I'm hoping that the answer will be no :-) )
We've came across a strange user-agent string in our server logs. A browser (pretending to be an iOS Safari 9.0) had WalletPasses/1.2.3 at the end of the user-agent HTTP header.
What's that device or software?
A quick Google search reveals https://walletpasses.io. From there:
Wallet Passes allows you to use your Apple® Wallet / Passbook® Passes on Android™
So I'm guessing that they're spoofing the iOS Safari user-agent to make websites offer Apple Wallet to them.
I'm making a PWA and is hosted on Firebase. I can see my page in Chrome, IE and other browsers. But I have problems with Safari and Opera. I have SLL certificade and TLS 1.2 (both from firebase) with nginx as server.
I tested my page on browsers and I get errors like:
"Safari can't open the page -url- besause safari can't establish a
secure connection to the server -url-"
"Can't establish
communication with protocol SSL/ TLS"
"Fatal Error (70) from
server " (Opera/Debian)
And in htbridge I got:
*HTTPS protocol, failed CSP status
*Many "The header was not sent by the server."
*I don't have have a Certification Authority Authorization (CAA) record.
*No support of TLSv1.3
*Server doesn't provide HPKP
So, I guess is something about security. But I don't know why it can be the main problem.
I tried to correct some stuff some commands on the server (nginx) but I don't know where is that or what I need to do. I am new to these things and I need someone to guide me a little at this point.
What should I do or is something I don't know?
Opera is exactly following the footsteps of Chrome, so if it works on Chrome shouldn't be problem on Opera, i would say just uninstall the Opera and re-install it. Also, check what versions you have got? to get he maximum of both browsers you need latest versions. Also, there are certain restrictions on Safari regarding PWA and service worker. Although, both Safari and MS Edge working on it and all the main browsers are getting into the same page on the issue of PWA (i.e. Service worker, Cache Api and IndexedDB).
It turns out that I was testing on obsolete versions of Safari and Opera for Windows. For some reason it did'nt work on a specific iphone and hence my confusion. Thank you for your help!
I'm exploring the idea of HTTP Origin checks as CSRF protection for Drupal at https://www.drupal.org/node/1803712
Now I was testing how the Origin header arrives with a POST request, but Firefox does not send the Origin header on the user login form submission. Chromium and Chrome work fine, they send the Origin header.
Firefox version is 36.0.1. I also tested with a clean Firefox installation because I thought maybe some of my browser plugins suppress the Origin header, but no luck - no Origin header there either.
Is there a documentation page that describes when Firefox sends the Origin header and when not?
Is isn't implemented yet. There's a discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=446344
The default on Firefox is not to send HTTP_ORIGIN.
The reason is a bug that causes hangs on some mobile Firefox versions if the network.http.sendOriginHeader configuration variable (accessible via about:config) is enabled. (For details see https://developer.mozilla.org/en-US/Firefox/Experimental_features#Security and the link provided by Marco's comment https://bugzilla.mozilla.org/show_bug.cgi?id=446344.)
There is a proposal to enable FF sending HTTP_ORIGIN by default, but the TODO list is long (see https://bugzilla.mozilla.org/show_bug.cgi?id=1424076).
So it will probably take years until FF will generally send HTTP_ORIGIN even without Javascript code enabling CSRF.
Some FOSS OSes preconfigure their FF ports to send HTTP_ORIGIN by default.
BTW, MS Edge also does not send HTTP_ORIGIN without explicitly enabling CSRF using Javascript.
For this reason I have implemented a security setting of my site which enables the users to disallow POST transactions from browsers that do not provide HTTP_ORIGIN.
I am writing a web app using SignalR cross domain communication. I am using the latest version of SignalR, 1.0.1. Following is the code in the jQuery's document ready event:
var connection = $.hubConnection(url);
var proxy = connection.createHubProxy(hubName);
connection.start().done(function () {
proxy.invoke('serverMethod');
});
I tried running the application on Opera, Firefox, Chrome and IE 10. My OS is Windows 7. It works well on IE 10 and doesn't work on other browsers. I changed mode of IE using developer tools to IE 9, and it stopped working. The same code works on all browsers if I use SignalR version 0.5.3.
In developer tools of the browser, I found the following HTTP status code in response of negotiation request: "HTTP/1.1 403 Forbidden".
Am I missing anything here? What is the reason because of which it is breaking on browsers other than IE 10?
Ensure that in your MapHubs call that you enable cross domain.
RouteTable.Routes.MapHubs(new HubConfiguration() { EnableCrossDomain = true });
When testing cross domain locally IE10 has an interesting feature that treats any localhost port as not being cross domain.