Xojo.Net.HTTPSocket Changed

I developed an application that uses Xojo.Net.HTTPSocket using Xojo 2018 R3. Application has been working fine. I just upgraded Xojo 2018 R4 and now I am getting the following error from my Xojo.Net.HTTPSocket module.

http Error: -1022 The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.

There have been no changes to the code around this. If I recompile with Xojo 2018 R3 it works fine. Can anybody confirm if something has changed? I went through the docs and forum but have not found anything. Has anybody encountered this?

Thanks

macOS now requires that your internet requests are secure. URLs that you are requesting should all be “https://” URLs.
If for some reason you cannot use secure communications, there is a flag you can put in Info.plist to declare you need insecure communications. I do not recall what this flag is off the top of my head, but I believe AppWrapper can set it for you.

See this Xojo blog post…
link text

Gents,

Thank you for the update I was not aware of this change. I tested the implementation in the article that Roger shared. It’s easy enough to do. Unfortunately, this will present a challenge for my application since the URL that will be used is unknown until run time.

This is an app that will access diy print server. The print server code is caned but the URL it is accessed via will be up to the builders discretion and is not https ready. How best to deal with this particular situation?

Maybe this Link: https://www.nowsecure.com/blog/2017/08/31/security-analysts-guide-nsapptransportsecurity-nsallowsarbitraryloads-app-transport-security-ats-exceptions/ and the there mentioned NSExceptionAllowsInsecureHTTPLoads Key may help. But i am sure, you will have to explain this exception in detail to the MAS Review Team beforehand.

see this

I landed on the NSAllowsArbitraryLoads key for the moment. While I am all in favor of more security if it’s too restrictive it’s just as useless. People will find a way around. Can the plist be built on the fly by the end user. I won’t be able to come up with a single config that works everywhere and will need to build a process for dynamically modifying per user needs.

To be clear, this is not a Xojo restriction. This comes from Apple.

Not a good idea and probably prevented by the OS anyway. The plist is in the App bundle and you don’t want to be messing around in there.

If you’re not in the Mac App Store you can just use the NSAllowsArbitraryLoads key and not worry about it.

If you are in the Mac App Store you’ll also have to use the NSAllowsArbitraryLoads key and include enough reasons why with the submission so that Apple will still approve your app with it.

I suspected that Apple will likely push back on this. So my question is, what is the best approach when the URL can not be predicted and https is not an option? I don’t want to circumvent security, I do understand the value of security. Starting to sound like the preverbal rock and a hard place.

If I were in your position, I would implement the NSAllowsArbitraryLoads key, submit the app to the MAS explaining your reasons for doing so, and see what the reviewer says. Maybe someone has another option for you, but I can’t see one.

Thank you for the feedback and suggestions. I have a direction to move in.