macOS/iOS App Transport Security Error in FMX by Malcom Grove
May 6th, 2020 Posted by Malcolm Grove
May 6th, 2020 Posted by Malcolm Grove
[SHOWTOGROUPS=4,20]
Recently we were updating a system we had built for one of our customers. One of the things we needed to do was update the macOS applications for 64bit.
There are 3 applications in the suite that support macOS, and the first two converted very smoothly thanks to the 64bit macOS support in RAD Studio 10.3.3. Pretty much all that was needed was a recompile and to run them through the automated test suite.
However, the third one was a little trickier, so I wanted to document it here for anyone (including me) who strikes it in future.
I need to give a little context about what this particular app does. It allows their users to create template files that are then used to automatically generate config files used by a few of their internal systems and equipment. The Templates are just text files, but embedded in them are tags that they can use to pull in data from different sources: files on disk, a database, from one of their internal systems, even a http(s) url.
This particular app compiled no problems, and even passed tests with a few different templates we had setup. However one template, the one that included a tag to pull in data from an external http URL, failed, triggering the following error:
Unfortunately the customer didn’t control all the URLs they needed to pull data from, and indeed some were not using https. So we needed to change this policy for this app.
In the Apple world, you typically do this sort of thing through the info.plist file in your Application Bundle. Для просмотра ссылки Войдиили Зарегистрируйся. Combine this with Для просмотра ссылки Войди или Зарегистрируйся and it was relatively straight forward, once we knew what was going on.
In the Project directory you’ll find an info.plist.TemplateOSX.xml file, which is the template RAD Studio will use to create your info.plist file.
We needed to edit this to add the additional keys needed to enable HTTP access. Now, if it had been possible, I’d have preferred to whitelist the specific insecure URLs they needed. That is supported by Apple, so we could allow these two or three URLs, and not any others. However, in this case the customer couldn’t predict ahead of time which URLs they would need. They varied depending on their clients, so we were left with having to turn on HTTP access altogether.
I don’t recommend this, unless it’s really needed and your user fully understands the consequences. Also be aware, that if you are looking at deploying via the App Store, Apple’s review process will look closely at these security settings and may reject if they feel the loosening of the defaults is not justified.
OK, warnings out of the way, our info.plist.TemplateOSX.xml file ended up looking like this:
With that change and a recompile, our macOS tests all passed.
As mentioned above, according to the docs this also affects iOS, and should be fixed in mostly the same way. However, we haven’t hit this issue on our mobile projects yet, so can’t confirm.
[/SHOWTOGROUPS]
Recently we were updating a system we had built for one of our customers. One of the things we needed to do was update the macOS applications for 64bit.
There are 3 applications in the suite that support macOS, and the first two converted very smoothly thanks to the 64bit macOS support in RAD Studio 10.3.3. Pretty much all that was needed was a recompile and to run them through the automated test suite.
However, the third one was a little trickier, so I wanted to document it here for anyone (including me) who strikes it in future.
I need to give a little context about what this particular app does. It allows their users to create template files that are then used to automatically generate config files used by a few of their internal systems and equipment. The Templates are just text files, but embedded in them are tags that they can use to pull in data from different sources: files on disk, a database, from one of their internal systems, even a http(s) url.
This particular app compiled no problems, and even passed tests with a few different templates we had setup. However one template, the one that included a tag to pull in data from an external http URL, failed, triggering the following error:
I’ve changed the URL to protect the innocent, but after a bit of digging it turns out that macOS v10.11 (and also iOS 9.0) introduced a new default security policy that prevents applications accessing http urls (ie. not https).
Unfortunately the customer didn’t control all the URLs they needed to pull data from, and indeed some were not using https. So we needed to change this policy for this app.
In the Apple world, you typically do this sort of thing through the info.plist file in your Application Bundle. Для просмотра ссылки Войди
In the Project directory you’ll find an info.plist.TemplateOSX.xml file, which is the template RAD Studio will use to create your info.plist file.
| 1 2 3 4 5 6 7 8 | <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "Для просмотра ссылки Войди <plist version="1.0"> <dict> <%VersionInfoPListKeys%> <%ExtraInfoPListKeys%> </dict> </plist> |
We needed to edit this to add the additional keys needed to enable HTTP access. Now, if it had been possible, I’d have preferred to whitelist the specific insecure URLs they needed. That is supported by Apple, so we could allow these two or three URLs, and not any others. However, in this case the customer couldn’t predict ahead of time which URLs they would need. They varied depending on their clients, so we were left with having to turn on HTTP access altogether.
I don’t recommend this, unless it’s really needed and your user fully understands the consequences. Also be aware, that if you are looking at deploying via the App Store, Apple’s review process will look closely at these security settings and may reject if they feel the loosening of the defaults is not justified.
OK, warnings out of the way, our info.plist.TemplateOSX.xml file ended up looking like this:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "Для просмотра ссылки Войди <plist version="1.0"> <dict> <%VersionInfoPListKeys%> <%ExtraInfoPListKeys%> <key>NSAppTransportSecurity</key> <dict> <!-- Include to allow all connections; avoid if possible --> <key>NSAllowsArbitraryLoads</key> <true/> </dict> </dict> </plist> |
With that change and a recompile, our macOS tests all passed.
As mentioned above, according to the docs this also affects iOS, and should be fixed in mostly the same way. However, we haven’t hit this issue on our mobile projects yet, so can’t confirm.
[/SHOWTOGROUPS]
