Complete
over 5 years ago

Garmin Connect Mobile 4.22 for Android includes the changes to allow HTTP on 127.0.0.1.

Connect version 4.20 broke local http access?

Getting several reports of functionality no longer working, it looks like Android Garmin connect app version 4.20 may have broken web request to local host via urls like http://127.0.0.1:17580/sgv.json?count=3

Horsetooth
Parents
  • over 5 years ago in reply to Stephen.ConnectIQ

    I have another use case. My app (Garmoticz) is a frontend for Domoticz: Controlling lights and other smart equipment using a garmin watch.

    The domoticz server is an IP adress on the local lan (probably a raspberry pi running domoticz). A lot of users will only control switches when connect with WIFI to local LAN. So their will be no domain name, and no certificates and therefor no SSL connection. 

    For thse users i need the HTTP connection to be working. I currently advise them to downgrade to GCM 4.19

Comment
  • over 5 years ago in reply to Stephen.ConnectIQ

    I have another use case. My app (Garmoticz) is a frontend for Domoticz: Controlling lights and other smart equipment using a garmin watch.

    The domoticz server is an IP adress on the local lan (probably a raspberry pi running domoticz). A lot of users will only control switches when connect with WIFI to local LAN. So their will be no domain name, and no certificates and therefor no SSL connection. 

    For thse users i need the HTTP connection to be working. I currently advise them to downgrade to GCM 4.19

Children
  • over 5 years ago in reply to FlowState

    totally agree.

    desired behaviour should be allow http for localhost and local/private network, to allow to communicate with devices the local network.

    In addition: If for whatever reaon https is enforced, the error code should be correct (1001 instead of 300), Because with current implementation, i cannot create the correct user friendly error to the user.

  • over 5 years ago in reply to jim_m_58

    Yes I understand what you meant too. I just don't see why you'd limit it to 192.168.* and not include 10.* and 172.16.*.

    Some orgs use all 3. To be fair, most consumers wouldn't.

  • over 5 years ago in reply to FlowState

    Sorry: obviously I should amend my post to read:

    "e.g. If your IP address is 192.168.0.1, then no router will ever pass traffic between you and the internet."

  • over 5 years ago in reply to FlowState

    I understand that.  It's just that 192.168 is the most common being class C and the default on may things.  There's one block for class A, one for class B and one for class C addresses

  • over 5 years ago in reply to FlowState

    To be clear, the IPv4 (and IPv6) standards already have clear notions of which IP addresses are local/private/non-routable and which are not (as alluded to above). e.g. If your IP address is 192.168.0.1, then no router will ever pass traffic between you and another network. My understanding is that Apple chose to allow HTTP for all IP addresses, but they could've easily just decided to apply that policy to the non-routable IP addresses.