We are trying to implement iOS Over The Air (OTA) installation on our MVC3 website that uses Forms Authentication.
The installation page is only available to authenticated users. We also want to lock down the actual *.plist and *.ipa files using Forms Authentication. This is to prevent someone from trying to install the file directly if they know the url.
Once we put all the security in place, we are unable to successfully install the app. The iPad browser returns an error: “Cannot connect to XXXX.com”. If we allow all users access to the folder where the files reside, the installation completes successfully.
Herein lies our problem. It seems that the OTA installation request does not include the authentication cookie in its request. Currently, this is our best guess as to what is happening because when we allow all users access to the folder everything works fine. Also, we checked the IIS logs and it seems to point to the same conclusion.
Here is the pertinent log file information:
2012-04-05 20:42:37 XXX.XXX.XXX.XXX GET /[WEBSITE]/[SECURED FOLDER]/[FILE].plist – 80 – XXX.XXX.XXX.XXX iTunes-iPad-M/5.0.1+(32GB) 302 0 0 46
2012-04-05 20:42:37 XXX.XXX.XXX.XXX GET /[WEBSITE]/login ReturnUrl=%2f[WEBSITE]%2f[SECURED FOLDER]%2f[FILE].plist 80 – XXX.XXX.XXX.XXX iTunes-iPad-M/5.0.1+(32GB) 200 0 0 15
Our interpretation of the log files is that the request to /[WEBSITE]/[SECURED FOLDER]/[FILE].plist is denied and a 302 is returned. The next request logged is to the application’s login page with the path to the plist file as the return url: /[WEBSITE]/login ReturnUrl=%2f[WEBSITE]%2f[SECURED FOLDER]%2f[FILE].plist
Any ideas as to how we can overcome this?
In the end, our suspicions were correct. The OTA installation request does not include the authentication cookie in its request.
To get around this and still have some level of authentication, we removed the security restrictions on installation files. We then added a one-time usage verification key to the link to the OTA location.