Safari push notifications return denied without asking

Question

Im trying to use the new push notifications in Safari. I'm using the following snippet:

var checkRemotePermission = function (permissionData) {
  if (permissionData.permission === 'default') {
      // This is a new web service URL and its validity is unknown.
      console.log("default");
      window.safari.pushNotification.requestPermission('https://website.com/','web.com.website.notify',{uid: "TEST"},checkRemotePermission);
  }
  else if (permissionData.permission === 'denied') {
      // The user said no.
      console.log("no");
  }
  else if (permissionData.permission === 'granted') {
      // The web service URL is a valid push provider, and the user said yes.
      // permissionData.deviceToken is now available to use.
      console.log("yes");
  }
};

if ('safari' in window && 'pushNotification' in window.safari) {
    var permissionData = window.safari.pushNotification.permission('web.com.website.notify');
    checkRemotePermission(permissionData);
}else{
  alert("This feature is only available on Mac OS X safari")
}

The problem is that I get no in my javascript console, because the permission is denied. The thing is it never asked, nor has it ever asked before. Its not even in my safari preferences.

Why does safari return denied without even asking?

Answer 1

This error can happen when testing locally because the address you are testing from isn't part of the allowedDomains array in the site's pushPackage. For https://zeropush.com, we added the host lvh.me to our pushPackage and ran the server on port 80, while we were implementing safari push notifications. You then access your development site at lvh.me and things should behave normally.

You should also implement the logging endpoint for your site described in the safari push notification docs so that you can get any error log information to help you in debugging.

I also wrote a post about implementing safari push notifications that is somewhat ruby centric, but may be of use. https://zeropush.com/blog/implementing-safari-push-notifications-in-osx-mavericks.

Answer 2

It seems that this behavior can occur when testing "locally" on your machine with a "self-signed" SSL certificate.

I was seeing this exact same behavior while attempting to get Safari Push Notifications working in a Rails 4 app locally on my machine. I was using nginx with a self-signed SSL certificate generated on the command line.

I was using javascript code very similar to yours, and I'd constantly see a "denied" output form my debug console.log statements, yet no prompt was ever displayed to the user requesting their permission to send them push notifications.

After one such attempt, I checked Console.app on my machine. It was then that I found this little cryptic, yet seemingly related/helpful nugget of info:

SafariNotificationAgent[65893]: NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9812)

This, coupled with a few responses with similar guesses from the official Apple Developer Forums, leads me to believe that the self-signed SSL certificate is the culprit in this case.

I'd love to hear anyone else's ideas on a better way to go about testing Safari Push Notifications locally.

Answer 3

I got the same problem when testing Notifications locally! But I found a solution: if you copy the file to your Sites folder in your home folder and access it via the included apache (e.g.: http://localhost/~username/notification.html) it will ask you for permissions and work as expected :)

Answer 4

Initially, the permission is set to default due to which, safari makes a post call to download the pushPackage to your webserviceURL. Safari would return denied even if your pushPackage is invalid in any way. Refer to the flowchart given here and also the error logs

https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html

You would also need a valid SSL Certificate(not self signed) as already mentioned. Best Practice would be to implement /version/log to diagnose the errors.