Possible workarounds for APIs which support only HTTP

Former Member over 6 years ago

Hi All

Understand that makeWebRequest supports only HTTPS and not HTTP.
However, the API I need to access uses only HTTP at this point of time.

Could any kind soul share the possible workarounds?

So far, I am looking into either setting up a Apache server to act as a proxy or using a companion application (Android / iOS) to workaround this. Both seems to be an awful lot of work for a simple application thus trying to find a simpler way.

Thanks!

Top Replies

All Replies

0 Travis.ConnectIQ over 6 years ago in reply to dpawlyk

> Android added a restriction but also allowed apps to have a work-around. That's the part of the history you keep avoiding.

I'm avoiding nothing...

I've never said anything about Android having such restriction, about there being a workaround for such a restriction, or that Garmin opted not to work around such a restriction. I have literally never heard of any of this on Android until now.

I've even googled, and I still see nothing to indicate that there is, was, or will be such a restriction on Android. Could you please link me to some actual information?

0 dpawlyk over 6 years ago in reply to Travis.ConnectIQ

Do you even know what this thread is about?

https://www.thesslstore.com/blog/https-will-now-be-the-default-for-all-android-p-apps/

And this thread (linked to in the present thread).

https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-version-4-20-broke-local-http-access

-----------------------------------------

Offline Brandon.ConnectIQ 4 months ago in reply to Jan Čapek

I don't have any specific updates on this yet, but it's being looked at by the GCM team. I think there are a lot of strong use cases mentioned in this thread, and the suggestion that non-routable addresses should be available over HTTP seems entirely reasonable to me.

The earliest that this could be addressed is in the next GCM release, which should be later this month (GCM is on a monthly release cycle), but I can't say whether that's a realistic expectation. We're doing what we can to keep the GCM team aware of the impact to all of you and get decisions made. I apologize to everyone for the road block this has imposed. While jim_m_58 is correct that we advised switching to HTTPS in 2017, this clearly hasn't been strictly enforced and we apparently had a blind spot with regard to some of these use cases that require HTTP.

I'm optimistic that we'll have a solution, but it's unclear to me the time frame required to get one in place.

-----------------------------------------

Brandon.ConnectIQ 4 months ago

The impetus for this change is, of course, Android Pie:

https://www.thesslstore.com/blog/https-will-now-be-the-default-for-all-android-p-apps/

My understanding is that it's possible to add exceptions for domains/IP addresses in the network security config. We're evaluating what we can do without exposing security holes that the new HTTPS requirements on these mobile platforms are attempting to address.

I agree with the point made by Flowstate, but I don't know that we'll be able to go that far. I'd like to get a better understanding of what's needed vs. what would be nice to have. For example, would allowing an exception for localhost address the majority of the issues discussed in this thread? I know this doesn't help the home automation apps that are talking over private networks, but it would allow anyone using apps that leverage NanoHTTPD to get back up and working.

0 dpawlyk over 6 years ago in reply to dpawlyk

It seems Apple removed the restriction way back for iOS 10.

I have no idea why anybody is talking about Apple with a new issue with Android.

https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsallowslocalnetworking

In iOS 10 and macOS 10.12 and later, ATS allows all three of these connections by default, so you no longer need an exception for any of them. However, if you need to maintain compatibility with older versions of the OS, set both of the NSAllowsArbitraryLoads and NSAllowsLocalNetworking keys to YES.

Note

While ATS doesn’t block local loads by default in newer versions of the OS, consider setting NSAllowsLocalNetworking to YES as a declaration of intent, if appropriate, even if you don’t support older OS versions.

0 jim_m_58 over 6 years ago in reply to dpawlyk

Since you're talking about Iot and CIQ, I'll just say that since the localhost fix on Andrioid, I've seem no other complaints but yours. That kind of tells me it's not that big an issue.

And there are ways to do Iot without a change in GCM.

Here's an example: https://apps.garmin.com/en-US/apps/7bcba0b7-a506-4226-81f8-d77e1775b47a

A watch face that pulls data from an Iot device "(for example Arduino weather stations)"

While using a web based service adds complexity, I know from my own experience it adds flexibility (I had an app for my Home Automation system almost 5 years back) as there were times you want to check on things when you're not at home - in fact, I find that more common when I'm not home. My current project is a widget to control the Garage door over BLE using a Raspberry Pi, with info like the garage temperature.

What is your use case?

0 dpawlyk over 6 years ago in reply to jim_m_58

???

Having a restriction doesn't "add flexibility".

Lacking the restriction doesn't keep you from using a web-based service.

While it's nice that a web based service works for your case, it makes no sense to require it if it's not needed or not wanted.

Sure, there are "other ways" but they are a lot more work to do something completely unnecessary.

And, now, we have different behavior between iOS and Android, which is bad.

=======================

There were other complaints in the other thread.

My app can pull files from a PC. It's a feature other people have expressed interest in. Having to use https makes that impractical. No one really uses encryption on private networks.

It works over WiFi but not all devices can do that.