We have an enterprise distribution of an app that we would like to distribute only within our organisation.
We've built the ipa file and the plist which points to the right places, and created the html page with the url: itms-services://?action=download&url={link to our plist}.
Our problem however is securing the distribution process. We want our employees with company owned iPads to be able to download the app while on the move (they're highly mobile). So we want to place the plist and the app on a public website which requires login via an oauth service.
Our problem is that if we require authentication on the URLs for the app and the plist, the itms-services:// url no longer works. What happens is that the user clicks the itms-services link, and we see an un-authenticated request for the plist (which is redirected to login) followed by a "Cannot connect to {hostname}" on the device.
At the moment, the only way I can see this working is if the ipa and the plist files are not checked for authentication. This means (I believe) that someone guessing our URLs to our plist file could create their own itms-services link and download the app without authorisation and effectively cause us to violate our agreement with Apple to only distribute to our employees.
My question therefore is - how can I create an itms-services link that does not expose the ipa and plist files to the public? If it's relevant, the website is built using nodejs and the app is a PhoneGap app.
I've figured out a solution to this.
We can't use the oauth authentication because the iOS install process doesn't present the opportunity to enter credentials.
Instead, when the user requests the page which we display the itms-services:// link on, we create a unique string to that user and encrypt it using AES-256, then store it in the database.
Our URL then becomes: itms-services://{url to plist}/{encryptedString}
. We tried using a query string, but it appears the iOS install tool doesn't pass that on.
When the install tool requests the Plist, we verify the encrypted string against the database, open the plist and rewrite the url to the ipa file to {url to ipa}/{encryptedString}
.
This seems to work quite well. The only issue I can think of at the moment is that the URL could be shared publicly be a legitimate user with someone who shouldn't have access. I think we could get around this by ensuring the url is time sensitive (e.g. only available for 5 minutes).
Finally, any requests to the plist or the ipa without a correct encrypted string get rejected.
I hope that's useful for someone!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With