In our new Azure based project, we are working for the last few months now. Now it is time for us to work on push notification. And there are some decision to be made here.
When one of the “pundits” was asked what he was thinking about particular subject, his answer was “I don’t know, I didn’t write about it yet”. I mostly made these decision, let’s put them in writing to think it through again.
Your decisions need to be based on what you are doing. This is our setup.
- All our users need to be authenticated to use our application.
- Currently we are working on push notification for messages, but later we can add more, like some kind of alerts.
- We use iOS and Android as a platform for out mobile applications.
There are two ways how mobile application can register itself for push notification in Azure notification hub. One is using direct API of notification hub, another is through App Server API, which is developed by you. The latter approach is described here. I believe that the choice between these two approached is defined by authentication. If all of your users required authentication, it means you probably need to send targeted notifications, which means one of your tags is going to be user identification. This is where vulnerability is. If you know (guess) the user identification, it is very easy to subscribe for other users notifications.
If registration is done by app server, it will be done when user is already authenticated, and our tag should not be user’s login. Instead, it should be some id that is used internally, and never exposed outside of the backend.
My problem with the second approach, at least in the way it is described in the link us/library/dn743807.aspx, is that now backend needs to have platform specific code, by setting different templates depending on the platform of the caller. So, to that example we made our own modification. We decided that our API should accept the template from the mobile application itself. Both mobile app and should have some agreement about what to expect in the notification, but doing this we can abstract ourselves from the specifics of the platform in the backend, which is the goals of the notification hub in the first place.
With this addition, we have the best from both approaches. Keep it secure and abstracted from the platform.