My organisation maintains multiple applications and there's a confusion about how the APNs keys are supposed to be used.
We are using firebase to send push notifications.
So far we have two apple keys for two different applications. But cannot create a third key with APNs activated.
This question indicates that we're supposed to use the same key for all applications.
My questions are:
If we only can create two keys for one organisation is one supposed to be used for production and one for testing/development?
If we use the same keys for multiple unrelated application (unrelated except that the apps are all created by the same organisation) what stops cloud messages from being pushed to the wrong application. Is it related to identifiers for apps?
Are we supposed to create a convention to circumvent the problem of sending messages to the wrong app? ( I don't actually think this is a very valid option. It feels very wrong.)
For example:
using topics with a prefix for each app?
create device groups, one for each app?
I've asked this question here as well: https://forums.developer.apple.com/message/415911#415911
The key is used to authenticate to the service. It identifies your organisation to the service.
The reason you can have two keys is so that you can create a new one before revoking the old one if the key is compromised.
When an app registers for remote notifications you receive an identifier that is unique for that app on that device. If you have multiple apps on that device each will get a different identifier.
When you send a push notification the identifier ensures that it gets to the right app on the right device.
You need to ensure that you store the identifier against the right app on your backend (or you may have different backends for different apps).
Related
I want to get some unique identifier to allow specific devices to accessing my API, but looking on internet there's no way to get it and it's against Apple Policy,
But I need to get one of unique ID (e.g IMEI, UDID, ICCID, MEID, ETC)
looking on react-native-device-info, it just have getUniqueID() that can changed
This is IDFV on iOS so it will change if all apps from the current apps vendor have been previously uninstalled.
How can I get a unique ID ios devices?
FYI: My app won't be release into AppStore
There are major privacy concerns when getting a unique ID from a device. You have a few options.
First, you could just add some form of authentication or login system. This could be per device, per user, or even 1 login for the entire API. You could also limit the API to only respond to certain controlled IP addresses.
Second, you could add a flag and have a different version for production then in development. Limiting access that way.
Third, on first launch of your app you could request a new token from your server. The device would then store that token and the server would as well (to ensure no duplicates). Then just take that stored token and send it to the server for every request.
But on the device level there are privacy concerns in unique IDs for each device. You have to build your own system to handle it depending on your needs.
I would suggest that the IDFV was designed to suit your needs, while maintaining some level of privacy.
It is supposed to allow you (a vendor) to identify a return visit while not allowing you (a vendor) to share a user's identity with a third party in a relatable way for the third party to data-mine.
If users are routinely uninstalling and re-installing all of your apps I would look at solving the distribution issue you have there. I would assume (although haven't tested) that an update of an existing app would maintain the IDFV.
I have two IOS applications and I want to send new message push notification on both applications through pubnub ? Is it possible ? As apple has different APNS certificate for different application and pubnub can use only one certificate at a time, is there any hack possible through which I can send push notification on multiple application ?
This is becoming a more common use case especially with the popularity of car/taxi dispatch applications where you have a driver app that communicates with a separate rider app. There are other use cases but this is the most common one.
Currently, the PubNub Account Dashboard only supports one push cert per key set which means you have a couple of workarounds until we do support multiple push certs per key set.
Two Apps
Use 1 set of keys as the primary keys where you do all pub/sub operations, presences, etc.
You would also include the mobile push payload (apns/gcm) in every publish you send.
One application will register for push notifications using this set of keys.
You will also publish the push payload only on the second set of keys that the other app will register for push notifications on.
That other app will also pub/sub, etc. on the first set of keys.
And each set of keys will have a separate push cert as you already understand.
One App
The alternative is to just have one app (so one push cert with one set of PubNub keys) and you provide a means for the end user to register as a user of one module or the other (modules == apps now). Then just only show the functionality/UI that applies to that type of user. I understand this provides for a larger app footprint and more restrictive release cycles with both modules (apps) in a single app.
Neither of the above solutions are optimal but it is what many customers are implementing for now. We do have the multi-push cert feature on the roadmap but it requires some other features to be in place before we roll this out. Please follow #pubnub Twitter account and the PubNub blog for announcements of this feature and other great improvements that are coming soon.
Questions (from the comments)
Lets say I have two apps, one is driver and another is rider, do I have to create two apps on pubnub and get two set of keys?
As far as I understood from your explanation, after creating two apps on pubnub, we will have to use one keys for chat and another for push notification, am I correct?
In case of using another keys only for push notification, how will it identify to which rider app or driver app it has to send push notification?
Answers
I am answering all three questions in one shot here. I hope this makes it clear.
Apps in the PubNub Account Dashboard are basically just organizational folders so they don't really have to have a direct relationship to an actual application, so it really doesn't matter if you create 1 or 2 Apps in this scenario. But I would create 1 App and two sets of keys: Primary keys and Secondary keys. Both of your iOS apps (Driver and Rider) will use the Primary keys for all pub/sub of messages.
But for push notifications, Driver app will register for push notifications only on the Primary key's push cert and the Rider app will only register for push notifications on the Secondary key's push cert. Whenever you publish a message to the Primary key, you include the push notification payload for APNS (pn_apns : { aps : { alert :...) and you also publish just the push notification payload on the Secondary key.
Assume a user has two iOS devices that support Passbook and that the user has both registered on the same iCloud account, and has Passbook toggled on for synching with iCloud.
If a user downloads an updateable pass (e.g. has webservice URL) through an app (via link) and installs the pass on device A, will device B go through the motions of registering the Passbook pass using the registration service/get serial number/get updated pass? E.g. from a different POV, must the server assume that the user can synch their updateable pass across different devices, and must it support multiple registrations of the same pass across different devices?
Background:
Our business wants to use passbook, and we naively thought we could use the device lib identifier to distinguish a device. Turns out that within a single update (manual or automatic update) the same pass (e.g. passTypeID+serial combo) can change device library identifer as part of their call to the registration REST service. So we thought we could at least handle this by always updating the most current registration entry with new details so we would at most have one registration.
This breaks if two or more devices can be synched and both automatically go through their own registration processes. Only one of the devices would have it's pass registered correctly, and it would be difficult to predict which device has a correctly registered pass. If this doesn't happen, we can hobble along with our current solution.
We have implemented a Passbook Plaform, and we support multiple devices for each Coupon, here is my example with my Mac, iPhone 5 and iPod.
I download the coupon from the Mac from the URL eg: https://passqlub.com:8443/passGen/Pass.seam?passId=71
Then I have the preview of the coupon and then I click to "Add to Passbook"
Like in 5-10 mins, the iCloud of both devices (iPhone and iPod) sync the coupon in both device. As soon as the coupon is downloaded to the Device, it get registered with to records (same serial, same PassType, but two deviceId and tokens)
If the platform want to send an update, it must get the serial and passtype and iterate over the devices and send the push notifications.
Hope it helps to clarify the sync of passbook on multiple devices.
You are correct in that it is not possible to use the device identifier to distinguish a user or a device. There are two reasons for this, firstly if a user has multiple devices and an iCloud account then the pass will automatically sync across all devices, and all devices will register with a unique device identifier.
Secondly, for security purposes, devices rotate their identifiers and tokens. When this occurs, the device re-registers with a new device identifier. Annoyingly, it does not deregister the old identifier. The only way you discover that a device identifier is stale is via the APNS feedback service. So if you are not regularly pushing updates to the pass, or you are not frequently checking the APNS feedback service, you will continue to accumulate device identifier records, when in reality the number of devices has not increased.
The only reliable way to uniquely target a pass is via a combination of serialNumber, authorizationToken and passTypeIdentifier. These three (or a combination of passTypeIdentifier and either of the other two), can act as a reliable primary key.
You might perhaps want to reconsider your schema and logic for targeting records. Apple's sample Passbook Server code contains a simple but effective SQLite schema for pass records and device records. In this example, device records are indexed by a concatenation of device identifier and serial number.
In any event, you should be considering your pass records independent to your device records. When you wish to update a pass, update the pass record, then identify the devices on which the pass is installed, retrieve their device tokens and send to the APNS server. When each device calls in to retrieve the update, you can always identify the pass record using a combination of serialNumber, authorizationToken and passTypeIdentifier.
I'm developing a iOS app. This app has two targets (free version and premium version). Then I want to send push notifications throw my Service Web.
So, Do I need two certificates? Because my app (free or premium) uses the same Web Service and the same database. And when I want to send a push notification, now do I have to store and look if it's one version or another?
Can I use one certificate? Can I merge two certificates in one?
Thanks.
You can't use one certificate, since each certificate it tied to an App ID, and the App ID is different for each App (it contains the bundle ID of the App which is unique for each App).
You must use two certificates, which means your server will have to know which Device Token belongs to which App, and use the appropriate certificate. Perhaps, when you send the device token from your app to your server, you should send some additional info that indicates which App sent the token).
My scenario is:
1) I have an developer account, which creates apps shown in app store.
2) Meanwhile, I have another enterprise account which joins the enterprise program, and is for creating apps used in my company.
I would like the second app to use data from the first app, for some internal advanced feature.
I know I could build a different package for the first app, using my enterprise provision file. However, it would be better if all the employees can use the real markeing version app, so they can help to test the real one.
My question is:
Is it possible to have my two apps (under two different apple developer account) share data?
P.S. I've read this article http://useyourloaf.com/blog/2010/04/03/keychain-group-access.html and I understand that the keychain group access should between apps with the same bundle seed ID. I sent this question just in wonder if there is anything I can do differently, as I own the two different account?
P.P.S.
I've also considered other options like pasteboard and openURL with specific URL scheme. If finally I found I cannot use key chain approach, I will use pasteboard instead. But I would like to know if the key chain approach is possible first.
Check out UIPasteboard, it can share data between apps, but you'll have to launch one app, have it write to the pasteboard and then switch to the other app and have it pull out the data.