Xdrip: https (ssl) support for local web services?

[tynbendad]

Garmin has been threatening to remove http support (because Apple is pressuring them i believe) from their web request API... they may have just done it, as their latest app release no longer works properly with xdrip+ web services (see https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-version-4-20-broke-local-http-access).

Can xdrip+ local web services add support for https? It seems this could eventuallly be needed regardless of how that garmin issue turns out (it may indeed just be a bug)...

[tynbendad]

Garmin just replied that it did intentionally remove http access.

[tynbendad]

(for tracking purposes, i've also opened a Spike issue here: https://github.com/SpikeApp/Spike/issues/204)

[jamorham]

xDrip web services do already support SSL, see https://github.com/NightscoutFoundation/xDrip/blob/master/Documentation/technical/Local_Web_Services.md#ssl-option

I think there will be some extra work needed though, as the certificate would likely fail the certificate chain verification as it isn't signed by a certification authority.

Unless we can get hold of a valid signed certificate for 127.0.0.1 which last time I checked they wont allow then we would need to add the xDrip certificate to the android trust store so that it will accept it.

I haven't investigated how to achieve this. Phones can be a bit touchy about things like that and display dire warnings in a persistent notification etc. It would need investigating..

[thedewi]

Slightly off-topic workaround, in case anyone comes here looking for one: the Nightscout Garmin apps are still working if your Nightscout is on https with a valid certificate.

[dabear]

The most logical fix here imho would be to garmin allowing http for localhost addresses that cannot be used with a ssl certificate, and forcing https for every other site.

[tynbendad]

@jamorham fwiw I tried https to access xdrip on my datafield (it has a setting where you can put any url) and it didn't work...

[tynbendad]

An alternative (that I'm sure Garmin will recommend) is to integrate xDrip with the Garmin sdk Android library... I don't have the time/patience/experience for it though, but someone else should go for it if they like.

[jamorham]

I'm not sure what the implications would be. @swissalpine would be the person to ask I think.

[tynbendad]

There is hope, Garmin just updated the issue that due to feedback they are considering an exception for localhost access!

[swissalpine]

@jamorham Sorry for my late reply I'm for two weeks in the austrian alps.
There is a possibility to communicate direct with xdrip+ beside the web service but unfortunatly you can't integrate this in watchfaces or datafields afaik. You can build widgets and apps with this technology but widgets runs only if they are active and apps consumes a lot of energy and breaks the smartwatch functionality. Two years ago I tested this api and it was very buggy, from time to time you have to restart your phone to reenable the communication.
Instead of changing the technology of the communication with xDrip+ I prefer to stay with the old version of Garmin Connect Mobile App (14.9.1) as long as possible.
If @tynbendad informations are correct this would be the better way!

[swissalpine]

Today one of the Garmin People confirmed that they will allow again http requests to local ip adresses. The question seems to be how long this will last ... Garmin Connect Mobile App Updates are scheduled monthly and I don't think they do it this month.

[explodus]

isn't there another alternative? if we have the original .cer and .key file from the bks file, we should be able to import it on the local android device and trust them. or am i wrong with this?

[ChrisJSLH]

A developer (akkaming) has posted what he believes to be a potential solution in the Connect IQ thread (https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-version-4-20-broke-local-http-access?CommentSortBy=CreatedDate&CommentSortOrder=Descending).

Is he on to something?

[jamorham]

@ChrisJSLH he is probably correct, Garmin would need to implement this or another fix which they haven't done so far.

[swissalpine]

Yeah! There is an official Garmin Statement posted today by Brandon from the IQ Team:
We have a fix implemented to include localhost (127.0.0.1) in the exceptions list for GCM, which should be available in an upcoming release.

[swissalpine]

Garmin has fixed their app Garmin Connect Mobile. With version 4.22 Garmin apps can communicate again with xDrip+.
@jamorham You can close this issue.

[tynbendad]

Yup, as there doesn't seem to be a good alternative to allowing http localhost, I'll close it. Thanks for all the input.

[explodus]

doesn't works for me. tried makeWebRequest on http://127.0.0.1:17580/sgv.json?count=1 and got a -104 and on https://127.0.0.1:17580/sgv.json?count=1 a -300. nothing changes for myself with 4.22

[explodus]

ok sorry, got it, forgot to change the ports to the right ones, it's working again