I am currently working on an application built in VS using a Xamarin Unified IOS project. one requirement of the application is the utilisation of push notifications. The issue is that our test device/application registers in the first instance without any issues, we can see the registration events in azure portals, and the azure service bus. I have also confirmed the initial registration using the 'Service Bus Explorer' application and the server explorer feature in VS.
The issue arises when sending the test push notification. According to all the logs I have access too the message is successfully pushed to apples APNS server and I can't see any failures being returned as part of the PNS request. However once this completed the device registration is removed and the notification never arrives on the test device.
My understanding is that the azure application hub handles PNS rejections itself in order to tidy up device registrations. This in and of itself is not a terrible idea, but due to a lack of logging, it's very hard to determine the root cause. I have done a ridiculous amount of googling for this one, and a lot of people suggest an issue with the apple certificates that are used. I have deleted, recreated, resigned, verified, both APNS certs and Provisioning profiles until I ran out of combinations. None of that has resolved the issue.
To make the issue more confusing, if I use a service such as 'http://pushtry.com' or 'http://pushwatch.com' and upload the certificate and device token, it will allow me to successfully push a notification to the device.
Am I missing something glaringly obvious? or is the notification hub absurdly difficult to setup and debug for APNS?
Any help you can provide will be appreciated, I would publish some code, but as I know that the device registers the correct device token, I don't see it necessary at this point, but please feel free to tell me otherwise. Many thanks.
What's also important to note, if you are using Azure Notification Hubs APNS, is that it will unregister devices if the application mode is not set to in production. Once you have deployed to the app store, you need to switch the "application mode" in your Azure Notification Hub from sandbox to production. Otherwise your device registrations will be unregistered.
I'm using the same token/key for both sandbox and production with no issues.
After many man hours and through luck rather than any kind of logical process, we determined that 'Azure Notification Hubs' have an in built validator for the apple device token that's passed up to the APNS. So even though there are multiple examples and answers out there that suggest submitting a device token without spaces or symbols to the notification hub, this is in fact the wrong approach. The device token should always be submitted to the 'Azure Notification Hub' in an 'as is' state, without any validating from within the Xamarin.IOS application. Although this seems like such a simple thing to overlook, there is a lot of contradictory evidence out there on google, and Azure's documentation says very little about the format of submitted device tokens. Anyway hopefully this will help someone else someday.
-- Edit --
Device Token format from Apple: < XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX >
Format that many online resources suggest it is passed to the notification hub as: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
without spaces or the '<' and '>'
However it should be passed through to the notification hub as it is received from Apple.
Related
For a few weeks there is an issue with Azure Notification Hub - we have a backend service that registers devices & schedules notifications. When one of the notifications is triggered, then we send it to Azure based on the device type (create the payload and all of that).
The response we get from azure is positive, the notification has been enqueued and is ready to be sent. However, it seems that Azure does not send them all. No error is thrown but only a small percentage is sent. It also does not seem to depend on the device type.
There are no logs to read - or none tha I can find and I cannot pin point the issue.
We have an endpoint that triggers the sending of a notification - we did a test run with 30 notifications (similar and different payloads for the same device) and it all went well.
Not sure how to troubleshoot this or what might cause this. I understood from the documentation that the device might be inactive and then the notification is deleted from the queue after a while. But it seems that the said device receives 1 out of 3 notifications (sent at the same time).
Any feedback would be appreciated.
Edit update:
After upgrading to the Standard plan, we managed to get some more information and it looks like Azure gives back a "Success" with a count of "1" but the device does not receive the notification - the problem is, this happens randomly. It's not always the same device that does or does not receive the notification.
Sorry this isn't a super helpful answer, but could you please open a support ticket in the Azure Portal for us to investigate your particular case? This does not seem like expected behavior so the team will have to look into the logs for your namespace and hub.
One immediate thought - there is de-duplication logic when sending notifications. So within a period of time (something like 15 minutes) if the same notification payload is being sent to the same device, Notification Hubs will automatically drop that duplicate notification.
We are able to send push notification to apple 12.x iOS devices. But it doesn't send notification to the iOS 13 devices. We tried the suggestion of adding "apns-push-type" value to "alert" in the notification header. But it doesn't work at all. It seems microsoft doesn't know how to fix it. They just like that told the change. We have tried many ways to solve it for last 1 week. But no success.
Apple recently updated their public Push service in a way that impacts Azure Notification Hubs customers. Learn more about the impact of these changes on Azure Notification Hubs. Specifically, Apple now requires that developers identify notifications as an alert or background notifications through the new 'apns-push-type' header in the APNS API.
Azure Notification Hubs updates for iOS 13 - I understand you mentioned "We have tried many ways to solve it", If you haven't tried these already kindly try and let us know for further investigation.
According to Apple’s documentation: "The value of this header must accurately reflect the contents of your notification’s payload. If there is a mismatch, or if the header is missing on required systems, APNs may return an error, delay the delivery of the notification, or drop it altogether."
Developers must now set this header in their applications that send notifications through Azure Notification Hubs. Due to a technical limitation, customers must use token-based authentication for APNS credentials with requests that includes this attribute. If you’re using certificate-based authentication for your APNS credentials, you must switch to using token-based authentication.
To help you during this transition, when Azure Notification Hubs detects a notification that doesn’t have the apns-push-type set, the service will infer the push type from the notification request and set the value automatically. Remember, you must configure Azure Notification Hubs to use token-based authentication to set the required header; please refer to Token-based (HTTP/2) Authentication for APNS for additional information.
Another minor change, but one that requires a change to the backend application that sends notifications, is the requirement that for background notifications the apns-priority header must be set to 5. Many applications set the apns-priority header to 10 (indicating immediate delivery), or don’t set it and get the default value which is also 10. This is no longer allowed for background notifications, so you must set the value for each request as Apple will not deliver background notifications if this value is missing.
For years, iOS developers used the description attribute of the deviceToken data sent to the push token delegate to extract the push token a backend application uses to send notifications to the device. With Xcode 11, that description attribute changed to a different format. Existing code developers used for this is now broken. We’ve updated the Azure Notification Hubs SDK to accommodate this change, please update the SDK used by your applications to the version 2.0.4 or newer of the Azure Notification Hubs iOS SDK.
Source -Azure Updates Azure Notification Hubs updates for iOS 13 (Posted on 21 October 2019). Copied the content here for more clarity.
In the article describing the registration management it states that:
The following are some key advantages to using installations:
Creating or updating an installation is fully idempotent. So you can
retry it without any concerns about duplicate registrations
What does it exactly mean? I assume it doesn't mean the installations have a 'CreateOrUpdate' unlike registrations, because a similar method also exists there - 'CreateOrUpdateRegistrationAsync'.
Suppose that I've created two installations with different installation ID but the same PNS handle (pushChannel property) and identical tag 'foo' present in both installations. I'm going to send a notification using the SendTemplateNotificationAsync method using the 'foo' tag to select the target of my notification.
It's going to match both my installations, because they both contain the tag 'foo' and both have the same PNS handle. Is the device going to receive two notifications, or is Azure going to prevent delivery of duplicates in this case?
In the the same article I've linked the code samples do check for existing registrations with the PNS handle that's about to get registered:
// make sure there are no existing registrations for this push handle (used for iOS and Android)
string newRegistrationId = null;
var registrations = await hub.GetRegistrationsByChannelAsync(pushChannel.Uri, 100);
but they don't check that in the installations samples, which again suggests that Azure prevents delivery of duplicate notifications.
Creating or updating an installation is fully idempotent. So you can
retry it without any concerns about duplicate registrations
Here, an installation is a term used to describe an enhanced registration (with Azure's Notification Hub) to associate PNS of the device with tag(s) and/or template(s). "Idempotency" here is used with regards to the act of such an installation.
What it means is that you can simply call the same code for this type of registration every time your app starts or is brought to foreground without worrying about handling changes in PNS or previous states of registration with the Notification Hub.
This is good because the classic registration model can lead to duplicate registrations for the same device and user in the notification hub. Installation model doesn't do that.
Q. What would happen when you have one PNS assigned to multiple registrations with same tag in the Notification Hub and you try to push a notification by targeting a tag?
A. Azure Notification Hub has de-duplication logic which will prevent duplicate notifications from going out.
Q. Can you force multiple notifications (for the same tag) in any way if you have multiple applications but one Notification Hub?
A. You can if you can get multiple device tokens. However, in case of iOS, as APNS issues only one valid device token at a time, it will not be possible. Also, iOS apps have their own bundle identifier and therefore their own specific push certificate. And, Notification Hubs don't support multiple certificates. But in case of Android, you can force it if you use registration model and use older GCM registration Ids as they are renewed frequently and don't expire so easily.
Hope that helps! Cheers!
I've set up an Azure Notification Hub and I have gone through all the steps to implement Push Notification into my iOS app. The app has been working fine, receiving the push notifications just like it should. Then today I went to try and send a push from the Azure Portal and it failed.
It seems to be only iOS related though, as the devices that run my app in Android are receiving the Push Notification like they should. I know for a fact I have not changed anything in my code. But instead of getting the Push Notification like I should I now get the following message in Azure portal.
The Push Notification System rejected the request because of an
Invalid Credential.
Any idea about this?
I have just resolved this issue. Just create new APNS certificates and add it to Azure Portal APNS settings. Now it works fine. But Why this is happened I don't understand that. If anyone have idea regarding this then please share it.
If any other solution then please share it here.
Thanks.
This is a potential explanation to your problem.
When you configure APNS into an ANH (Azure Notification Hub), you have the choice between 2 approaches:
Certificate
Token
Of what I understood, you have used "certificate", and APNS certificate expires every year:
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_certificate-based_connection_to_apns
So maybe, your certificate has expired, and when you created a new one, it has solved your issue.
The other approach with "Token", has the advantage of never expiring.
Regards,
Loic
I've set up an Azure Notification Hub and I have gone through all the steps to incorporate Push Notification into my Android app. The app has been working fine, receiving the push notifications just like it should. Then today I went to try and send a push and it failed. So I tried from the Azure Portal and it failed there too.
It seems to be only Android related though, as the devices that run my app in iOS are receiving the Push Notification like they should. I know for a fact I have not changed anything in my code. But instead of getting the Push Notification like I should I now get the following message in Azure portal.
The Push Notification System rejected the request because of an invalid credential
Does anyone have any idea why this would happen? I'm stumped.
I thought at first maybe it was something with my API key (which again I have not changed) so I checked. The Google Cloud Message API Key in the Azure Portal matches what I have in my Google API Console, so it's not that.
What could it be?
Ok, so here is how I fixed my issue:
In Google API Manager I used to only have an api key of type - Android
I created another key of type - Server, and copied that into my azure gcm config, and away she goes... notifications working again