No more local loopback connections via 127.0.0.1?

[gitanoco]

I have a watch face that fetches data from a local web service on my phone, which comes from an app that retrieves data from a body worn medical sensor.  The URL that I've used for this fetch request is "http://127.0.0.1:17580/...".  With the latest update to the fitbit Android app, this functionality seems to be broken.  If that is true, I'd like to obsequiously request that this be added back.  My whole reason for owning a fitbit versa is gone without this ability.

[gitanoco]

Been on 3.8 for a day and noticing a couple things:  The versa syncs and connects much more reliably w the companion app (my custom watch face that receives and sends data every 5 minutes is much more reliable) and battery life is better.  On 3.12.1 I'd be at 75% or less at one day, on 3.8 I'm at 83% after one day.

Hopefully 3.13 will get some of that magic back.

[snorre.hukkelaa]

Thanks @gitanoco that fixed the install issue.

However, it seems that sdk 4.0 has some kind of bug that messes with my application. 3.13 can't come fast enough.

[JonFitbit]

3.13 has begun rollout!

[gitanoco]

Installed.  So far so good regarding the local web server stuff.

[snorre.hukkelaa]

Did you manage to do a fetch to 127.0.0.1? I'm still getting "TypeError: Failed to fetch"

[JonFitbit]

---

@snorre.hukkelaa wrote:

Did you manage to do a fetch to 127.0.0.1? I'm still getting "TypeError: Failed to fetch"

---

Can you create a separate thread with more details about your configuration and usage?

[gitanoco]

Seems to be.

[snorre.hukkelaa]

@JonFitbit check out this thread:

https://community.fitbit.com/t5/SDK-Development/fetch-works-on-simulator-but-not-on-device-TypeError...

Let me know if you need more info 🙂

[TechFan7]

 Yes, I agree this is not a full solution.  Those IP addresses themselves should not be what is permitted. . .it should be all private network ranges as they are documented here:

https://en.wikipedia.org/wiki/Private_network

[LiamFitbit]

Unfortunately due to changes that Android made in recent Android API versions, we can't do that anymore.

Android made it so you had to whitelist hostnames or individual IP addresses, you can't whitelist an entire IP address range like you can on iOS. I'd suggest you direct this feature request towards Google, since we don't have any options to open this up more without risking making other functionality in the app less secure, which we aren't willing to do.

[TechFan7]

Hm.  That is definitely unfortunate.  I understand how it is challenging to provide reasonable security from your app when you are actually providing a route for all the custom developers within the entire community through your one app.  Unfortunately, this means that by tightening the Fitbit app, you are now potentially breaking the functionality for all the underlying developers.

I understand the dilemma.  I researched the change so that I could understand what is happening as well and I see how you are very limited.  I am glad that you have configured a few IP addresses into the allowed list.  Unfortunately, the first IP address is the private IP ranges is most likely already going to be the router for an environment in those areas.

After thinking about this for a bit, I wanted to make a suggestion that I hope you can/will consider putting in place.  I think that this would allow developers to still create apps that would not need to use HTTPS or if they did could at least be self-signed certificates.

My suggestion would be to configure several static virtual "domain" exceptions.  Then within the Fitbit app (maybe under developer settings/etc), provide a place where we could specify the IP to which the app will send such requests.  You could enforce that they had to be IPs in the private IP ranges (192.168.x.x, 10.x.x.x, etc).  Basically, you would be providing something like a host file (for DNS resolution) and be able to whitelist those limited domains much more easily.  Config being suggested:

  <domain-config cleartextTrafficPermitted="true">
    <domain includeSubdomains="true">customapp1.fitbit.com</domain>
    <domain includeSubdomains="true">customapp2.fitbit.com</domain>
    <domain includeSubdomains="true">customapp3.fitbit.com</domain>
  </domain-config>

 This would allow you to provide the HTTPS protection google is pushing everyone toward for essentially all traffic, but still permit solutions to the local LAN that can't properly support HTTPS (and probably never will be updated to support it properly, ie, only with a self-signed cert).  I hope this is something that might be possible.

[TechFan7]

Any chance this might happen?  I have a watch app that I would like to code, but it won't work unless I can somehow send the requests on the local LAN.

[hemanthn]

So we can never send any local network request through the fitbit watch app anymore? that's completely blowing all the IOT functionalities that 3rd party devs would want to support out of the water.

[Gondwana]

It can be done currently, with provisos:

• You can access any LAN device that runs a secure server (so, https/wss).
• You can access non-secure (http/ws) devices that run on the companion.

I believe that a forthcoming version of the Fitbit Android app will open up the LAN IP ranges that can accessed insecurely. Some standard LAN IP ranges will be allowed, but it won't be a free-for-all.

[hemanthn]

Hi Peter,

   Thanks for the quick response. 

Can you elaborate more on what you mean by 

"You can access non-secure (http/ws) devices that run on the companion."

Currently my app is trying to do a http post from the companion app to an ip address in the 192.168 range and its failing to do so.

[Gondwana]

@hemanthn Sorry for slow reply; for some reason I didn't see your post.

'on the companion' = same device on which the Fitbit app is running, which is probably your phone. It will probably be accessible via 127.0.0.1.