Magic TestFlight, or Learn more about Configuration Profile technologies and URL Scheme
On Habré there were already articles about TestFlight ( here and here ), but they dealt mainly with its use and integration / automation into the build process. And I was always wondering how it works from the inside:
• How is the collection of device identifiers? (If you don’t understand why UDIDs are collected, follow the links above.)
• How is the application installed by clicking on the link?
• How to create an icon on the Home Screen?
• Are they all hacks or legal methods?
If you want to build your TestFlight with blackjack and all the rest, or you are simply interested in how one of the above is done, I ask for cat.
')
It is assumed that the reader is already familiar with the TestFlight service and the pain of iOS developers - the need to collect the identifiers of iOS devices. Testflight allows you to get a UDID very simply - by installing the Configuration Profile.
A profile is an ordinary xml file that, thanks to the resolution of “.mobileconfig” and the format specified in the Apple documentation, is treated as a guide to action, that is, interpreted by the operating system as a description of the settings that need to be applied. The main purpose of the technology is the automatic configuration of a large number of iOS devices, used mainly in corporate environments.
A Configuration Profile may contain various blocks called Payloads; Each unit is a kind of functionality. Using the Configuration Profile, you can:
• Establish password policies
• Prohibit the use of devices or services
• Configure network, VPN access
• Configure IMAP, Exchange, LDAP, CalDAV accounts
• Create icons on Home Screen
• Install certificates
But how does all this help get UDID?
There is a special payload that does not set any settings. It is called Profile Service Payload and is used in the multistage process of incorporating iOS devices into corporate rows (Over-The-Air Enrollment and Configuration). To build such a system in full, you need a server with Simple support.
Certificate Enrollment Protocol (SCEP) - this is exactly what Testflight and similar services use. To support the SCEP protocol, there are paid (from Microsoft) and free open source solutions, such as OpenSCEP .
But, as it turned out, there is an easier way to get the UDID device - to implement only the first step of the whole process of taking the device into the corporate environment. This step is to request information from the device, so you can get the UDID, IMEI, ICCID, device MAC address, model (for example, iPad3.1 or iPhone4.1) and iOS version. To implement only this first step, an ordinary web server is sufficient.
So, your configuration profile might look something like this:
When a user installs his device information
will be sent to the specified SERVER_URL using the POST method. If you implement interaction via SCEP protocol, and the sent information should be answered
Special SCEP Payload. Read more about this in the Apple documentation . The final step in the exchange of profiles and certificates in the case of Testflight will be the Configuration Profile with Web clips payload, thanks to which a link to the service will appear on the Home Screen iOS device.
And this is, generally speaking, the only software way to create an icon on the desktop.
In case you are dealing with a corporate infrastructure, the configuration profile with all settings is sent to the device last. This profile is set by itself, without any additional questions to the user.
If your path is not to implement SCEP on the server, then it is not necessary to respond to the received information from the device. However, you need to keep in mind that after installing the profile, the user will receive an unpleasant message:
This development can be avoided by installing a redirect script in your handler, as suggested in one of the threads on the Apple Developer Forum. And here, in general, obtaining identification information from iOS devices can be considered complete.
Now let's see how TestFlight installs applications.
Each “tester” receives this “happiness letter” after building a new version of the application:
The Install button causes a link to follow the link:
• “itms-services” means using a Custom URL Scheme — a technology that allows applications to interact — call one of the other with passing launch parameters. It is not clear which application handles such links; similar links are known: “itms” - processed by iTunes, “itms-books” - iBooks, “itms-apps” - App Store. Most likely, this is a special system application that is responsible for installing applications. But not only system applications can have a custom URL, any application can register its own by specifying it in Info.plist. You can find out the URL of the application you are interested in and tell the URL of your application to the public through the special service handleopenurl.com.
• “url = http: //url/app-manifest.plist” indicates a manifest that stores a minimum set of application data: name, category, and directions for downloading the application binary and its icon. Such a manifest can be done using Xcode, if you select the distribution type “enterprise”.
• “action = download-manifest” - an action that must be performed by the called application and, obviously, means that the manifest described above must be downloaded.
As you can see, there are no particular difficulties in implementing a system like Testflight, but we continue to use this ready-made solution in Parallels, as we still don’t see any serious reasons for implementing an internal service.
The article was prepared based on a speech on Yandex Mobile Camp Spb.
• How is the collection of device identifiers? (If you don’t understand why UDIDs are collected, follow the links above.)
• How is the application installed by clicking on the link?
• How to create an icon on the Home Screen?
• Are they all hacks or legal methods?
If you want to build your TestFlight with blackjack and all the rest, or you are simply interested in how one of the above is done, I ask for cat.
')
It is assumed that the reader is already familiar with the TestFlight service and the pain of iOS developers - the need to collect the identifiers of iOS devices. Testflight allows you to get a UDID very simply - by installing the Configuration Profile.
A profile is an ordinary xml file that, thanks to the resolution of “.mobileconfig” and the format specified in the Apple documentation, is treated as a guide to action, that is, interpreted by the operating system as a description of the settings that need to be applied. The main purpose of the technology is the automatic configuration of a large number of iOS devices, used mainly in corporate environments.
A Configuration Profile may contain various blocks called Payloads; Each unit is a kind of functionality. Using the Configuration Profile, you can:
• Establish password policies
• Prohibit the use of devices or services
• Configure network, VPN access
• Configure IMAP, Exchange, LDAP, CalDAV accounts
• Create icons on Home Screen
• Install certificates
But how does all this help get UDID?
There is a special payload that does not set any settings. It is called Profile Service Payload and is used in the multistage process of incorporating iOS devices into corporate rows (Over-The-Air Enrollment and Configuration). To build such a system in full, you need a server with Simple support.
Certificate Enrollment Protocol (SCEP) - this is exactly what Testflight and similar services use. To support the SCEP protocol, there are paid (from Microsoft) and free open source solutions, such as OpenSCEP .
But, as it turned out, there is an easier way to get the UDID device - to implement only the first step of the whole process of taking the device into the corporate environment. This step is to request information from the device, so you can get the UDID, IMEI, ICCID, device MAC address, model (for example, iPad3.1 or iPhone4.1) and iOS version. To implement only this first step, an ordinary web server is sufficient.
So, your configuration profile might look something like this:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <dict> <key>URL</key> <string>http://SERVER_URL/enroll.php</string> <key>DeviceAttributes</key> <array> <string>UDID</string> <string>IMEI</string> <string>VERSION</string> <string>PRODUCT</string> </array> </dict> <key>PayloadOrganization</key> <string>parallels.com</string> <key>PayloadDisplayName</key> <string>Profile Service</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadUUID</key> ... When a user installs his device information
will be sent to the specified SERVER_URL using the POST method. If you implement interaction via SCEP protocol, and the sent information should be answered
Special SCEP Payload. Read more about this in the Apple documentation . The final step in the exchange of profiles and certificates in the case of Testflight will be the Configuration Profile with Web clips payload, thanks to which a link to the service will appear on the Home Screen iOS device.
And this is, generally speaking, the only software way to create an icon on the desktop.
In case you are dealing with a corporate infrastructure, the configuration profile with all settings is sent to the device last. This profile is set by itself, without any additional questions to the user.
If your path is not to implement SCEP on the server, then it is not necessary to respond to the received information from the device. However, you need to keep in mind that after installing the profile, the user will receive an unpleasant message:
This development can be avoided by installing a redirect script in your handler, as suggested in one of the threads on the Apple Developer Forum. And here, in general, obtaining identification information from iOS devices can be considered complete.
Now let's see how TestFlight installs applications.
Each “tester” receives this “happiness letter” after building a new version of the application:
The Install button causes a link to follow the link:
itms-services://?action=download-manifest&url=http://url/app-manifest.plist• “itms-services” means using a Custom URL Scheme — a technology that allows applications to interact — call one of the other with passing launch parameters. It is not clear which application handles such links; similar links are known: “itms” - processed by iTunes, “itms-books” - iBooks, “itms-apps” - App Store. Most likely, this is a special system application that is responsible for installing applications. But not only system applications can have a custom URL, any application can register its own by specifying it in Info.plist. You can find out the URL of the application you are interested in and tell the URL of your application to the public through the special service handleopenurl.com.
• “url = http: //url/app-manifest.plist” indicates a manifest that stores a minimum set of application data: name, category, and directions for downloading the application binary and its icon. Such a manifest can be done using Xcode, if you select the distribution type “enterprise”.
• “action = download-manifest” - an action that must be performed by the called application and, obviously, means that the manifest described above must be downloaded.
As you can see, there are no particular difficulties in implementing a system like Testflight, but we continue to use this ready-made solution in Parallels, as we still don’t see any serious reasons for implementing an internal service.
The article was prepared based on a speech on Yandex Mobile Camp Spb.
Source: https://habr.com/ru/post/150094/
All Articles