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
  • over 5 years ago

    Overhere in The Netherlands also trouble with the 4.20 version. I reinstalled the 4.19 version. Glad that this still works with my 3 months old Garmin edge 820!

    Please Garmin put us back online again with this app!!!

  • over 5 years ago in reply to Horsetooth

    Me neither.. 

    Any news here? Gosh, I am again so demotivated to invest anything more to this platform. :( Same thing happened last year when I encounter issue of weird compiler behaviour prevented me to continue with my plans with my other app and I got sensible response from Garmin team after 7 months - what a support... That is why I am not in the mood for any compassion in this topic. 

  • over 5 years ago in reply to usrusr

    >Kudos to Garmin for giving an early heads-up,

    kudos for breaking this now instead of breaking this later?  i don't quite get that.

  • over 5 years ago in reply to Brandon.ConnectIQ

    This does indeed not help for the home automation apps, but that does not mean we are out-of-options:

    The article also states that specific workarounds can be made in Android P:

    This change will apply to each every app that will be made available on Android P. Granted, there are some specific workarounds for apps or users that may require an HTTP connection. A specific declaration will need to be made in the app’s manifest if any HTTP connections are required. Users will be able to control this via Android P’s Network Security Configuration file. Is this something to look into?

    Or something else which would be better:: allow a self signed certificate for the 192.168.x.x networks?  a "no-check-certificate" and/or "private-key"  option to the webrequest, which can be used for specific use cases ?

  • over 5 years ago in reply to jim_m_58

    I don't understand the point here. If you use HTTPS, then you have to have a trusted certificate, for both Apple and Android, as far as I can tell. 

    You can't have a trusted certificate for localhost unless you get users to manually trust your self-signed certificate, or unless someone like Lets Encrypt decides to hand out certificates for localhost, which they won't, for obvious reasons.

    To further illustrate the point, most web browsers treat HTTPS with a untrusted certificate as even worse than HTTP -- the former is blocked (with an inconvenient opt-out procedure) while the latter just gives a warning (for now).