Search code examples
xamarinazureservicebusazure-notificationhub

Azure Notification Hub Register iOS Device Always Returns Unauthorized


Early on in developing an iOS app with Xamarin, another developer and I got push notifications working for it using the Azure Messaging Component. It's a few months later now, and sometime between then and now, the push notifications stopped working. The code is still basically the same as before (which is nearly identical to the example code for the component), it was just moved to its own class for maintainability.

On Hub.UnregisterAllAsync(DeviceToken, error =>, error is:

The operation couldn’t be completed. (NSURLErrorDomain error -1012.)

On Hub.RegisterNativeAsync(DeviceToken, tags, error =>, error is:

URLRequest failed for <NSMutableURLRequest: 0x167dbd80> 
{ URL: https://[our namespace].servicebus.windows.net/[our hub name]/Registrations/?$filter=deviceToken+eq+'[long token]'&api-version=2013-04 } 
with status code: unauthorized

We tried a new hub, and a new namespace with a new hub, but without luck. I've rolled back the changes we've made since it was working, but with no luck there either. The same error happens on multiple devices, on multiple networks. It never shows any errors in the portal for APNS, so I'm assuming this is something with authenticating to the Hub itself. What is really weird is that a Windows Store app that we wrote to test this registers and receives notifications using the same credentials without any issue. Can anyone point me in the right direction on this? The error messages above aren't very helpful.


Solution

  • It turns out that the test devices all had the automatic date and time synchronization turned off. The iPad I was primarily testing with was only off by about 20 or 30 seconds, so I didn't notice it was off. Another question involving the same thing with a Windows or Windows Phone registration clued me into it, but I can't find the link to it now. Apologies for that, thanks to whoever that was!

    Looking at the API, it makes sense why it's so sensitive to this. It uses the date and time to generate the SAS Token, thus the unauthorized response when the time is just a few seconds off.