I have an app A which is registered to apple to receive notifications and this generates "tokenA" which is passed to "providerA".
Now there is a another app B which is registered to apple to receive notifications and this generates "tokenB which is passed to "providerB".
So if "providerB" somehow gets hold of "tokenA" can "providerB" exploit the "tokenA" to send span messages to app A using "tokenA" ?
because both providerA and providerB has access to connect to apple servers.
From what I remember, the connection to the APNS server is over SSL with an application-specific certificate - so unless provider B also gets hold of the certificate, they shouldn't be able to send notifications.
I could be misremembering the certificate part, admittedly.
Related
I'm trying to verify that HTTP requests from iOS application were really sent from mobile application. Currently server code just checking 'User-Agent' HTTP header and of course it's not very reliable solution.
Here is how I see current iOS SDK can be used to verify that client is an actual iPhone user.
Push notifications
iOS app requests push token from the operating system and sends it to server
Server sends push notification to application with hidden identifier
iOS app sends received identifier to server
Server responds with cookie
Here on the first stages of communication we can verify that user is mobile user because how else she got identifier from push notification to specific app.
dis. Not quite reliable even if we can repeat push notification. Misuse of push notifications.
In-App purchase
It is possible to reuse receipt verification here.
dis. Obvious misuse. Confusing.
So the question is – are there any proper ways to confirm that request was sent from iOS application, from iOS device ?
iOS11 introduces new API https://developer.apple.com/documentation/devicecheck#overview
It looks like it solves the problem.
Is it true that we can use any component for our own server component? I mean it can be a Java or C# TCP/IP client which connects with Apple servers to push notifications. This can also be a console application, is that right?
Also, is it right that we have to push notifications for APN server, with each and every deviceTokens registered on our own server?
You can use whatever language you want and you will have to send push notifications for every registered device token. You should also investigate apple's feedback API's which you should periodically check to see which of your devices are no longer registered because sending a push has no feedback and you will not know if it is being received or not. If you use a service such as Urban Airship the setup will be much much easier to start and they have helpful API's to give them a group of device tokens or to do a mass push to all registered device tokens.
You are right on both accounts. You can write your own method to send it, and you must send it to each device id.
framework that might help you:
http://www.easyapns.com/
I’m looking at the designing and developing a service for Push notifications, and am trying to understand the order of processing in the Apple App when it comes to Registering for Push Notifications and storage of the Token.
What I’m developing currently is a service that allows subscription to individual changes that happen to particular processing on our server.
When they happen, the phone user may receive a message of type “A”, “B”, or “C”.
The phone user has to “subscribe” to each of these types individually if they want them. Otherwise they can ignore it and not subscribe.
So User Fred, on Phone #4, starts our App, logs in, and then has the ability to turn on or off subscriptions to events that are sent as Push Notifications.
So I need to tie details from Fred’s login, to Phone #4’s device Token, with particular subscriptions.
So my particularly important questions are.
When the Phone connects to the APNS server to get its device token, is this automatic on app start? Or can this be initiated at a later step? Ie, after going through a loging screen on our app.
Can we (are we allowed to) store the device token on the phone in the App's data store?. Or, should the App be connecting to the APNS server every time the app is run?
How does the App know if it as already called the APNS server and retrieved a token, or as above, should it call the APNS server time the app is run?
Can we (are we allowed to) store the token in the App’s memory as it runs, so we can properly subscribe and unsubscribe for particular messages?
We need also to be able to list all the subscriptions that a particular user may have across all their devices so the user can remove old devices (if they change phones). Or can we rely upon data back from calls to the APNS – when we attempt to push a notification - to inform us that a device token is no longer valid?
Or is there some better way of tying this all together?
When the Phone connects to the APNS server to get its device token, is
this automatic on app start? Or can this be initiated at a later step?
Ie, after logging into our app.
After the app has started, the app gets the token by calling registerForRemoteNotificationTypes. This will prompt the user for permission, and call a callback with the device token if permission is granted.
Can we (are we allowed to) store the device token on the phone in the
Apps data store?. Or, should the App be connecting to the APNS server
every time the app is run?
You'll need to build an APN provider, which is a web server that calls apple to send the pushes. The thing to do with the token is post it to your server that uses the APN provider. The app doesn't connect to APNS, your provider does, and it does it when it has pushes to send.
Can we (are we allowed to) store the token in the App’s memory as it
runs, so we can properly subscribe and unsubscribe for particular
messages?
You can keep the token on the client, but you don't really need to. It's your web service that calls APN, so it needs to be kept aware of your users' subscription prefs.
We need also to be able to list all the subscriptions that a
particular user may have across all their devices so the user can
remove old devices (if they change phones). Or can we rely upon data
back from calls to the APNS – when we attempt to push a notification -
to inform us that a device token is no longer valid?
APN also provides a feedback service that you call in batch which returns the device tokens that are no longer valid. Not only can you use this service, but you must. Apple will get mad at apps that repeatedly send to no longer valid devices.
Or is there some better way of tying this all together?
Yes! Parse.com provides a nice wrapper on the client code, does the provider and feedback service, abstracts the idea of single devices to the idea of a "channel" which sounds like just what you need for multiple notification types A, B, C, provides a super-easy step by step setup, and loads of other useful cloud services for iOS. (I'm not affiliated, but a big fan).
My application is in Appstore now and ı cant find out device tokens.is it possible to send push notification without device token
Simple answer: No, sorry.
Longer answer: No, you'll need to submit a new binary which collects the device tokens and submits them to your server.
You really should have sorted all of this out during testing with the sandbox before releasing to the AppStore!
The device will send your server a token to indicate that it wants to receive notifications. It is up to your server to store these tokens and send the appropriate messages to the devices as and when required.
Your server should also respond to people requesting to not have notifications any further and also for tokens that have become "inactive".
The app is for a Gym. I would like it to allow individual push notifications to be sent from trainers to their clients. Is this possible? Would registering the app with user name and trainer after downloading have any effect?
If your goal is to initiate a push message from one iphone app and have it delivered to another iphone, then yes it is possible. Typically in this type of scenario, your application would upload an APN device token to a backend server for each client that logs into your application. The backend server would then associate that token to that particular user. If you want to be able to handle multiple devices per user, then you will want to also include a unique device id with this registration.
When the trainers are using the application, they would tell the backend server to send a push message to one or more clients. Your backend would then retrieve the tokens associated with the clients to which the message is to be sent and use the retrieved token to send the message(s) to Apple's APN interface.
Remember the APN token is specific to the mobile device and application.