Fitbit blackout test reporting as failed???

[password1]

Got an unhelpful email today saying we failed the blackout test because we're making non-https calls. We updated our app months ago and have https everywhere. Not sure why fitbit doesn't give us a list of failed calls or summary.

How can I go about finding what your logs are reporting as non-https?

Or is this just another fitbit bug (like the xml response api calls), and was everyone possibly incorrectly spammed???

[password1]

Got an unhelpful email today saying we failed the blackout test because we're making non-https calls. We updated our app months ago and have https everywhere. Not sure why fitbit doesn't give us a list of failed calls or summary.

How can I go about finding what your logs are reporting as non-https?

Or is this just another fitbit bug (like the xml response api calls), and was everyone possibly incorrectly spammed???

[ibahdanau]

Please send me in a private message your consumer key so we can make better investigation why you got this email.

[aarondcoleman]

We got this email too, and at least one other user of the Fitbit.NET library got one. Can you update the group if in fact this was in error? No where in the Fitbit.NET library do we call the http endpoints, so I'm thinking maybe the emails went out incorrectly to some? If not and it's a library issue let me know and we'll publish a NuGet package update right away.

--Aaron

[aarondcoleman]

Update. The Fitbit.NET library appears to be completely tied to HTTPS already. HOWEVER, if you copied our example project's code here, note that you should update to add the "s" in https:

https://github.com/aarondcoleman/Fitbit.NET/blob/master/SampleWebMVC/Controllers/FitbitController.cs

So, to sum up, all the FitbitClient class calls already do connect using HTTPS, but it's that OAuth handshake that you need to specify with the "s". That's done via the Fitbit.Api.Authenticator class constructor. It should be:

 Fitbit.Api.Authenticator authenticator = new Fitbit.Api.Authenticator(
ConsumerKey,                                                                                    ConsumerSecret,                                                                                "https://api.fitbit.com/oauth/request_token",                                                                                    "http://api.fitbit.com/oauth/access_token",                                                                                    "http://api.fitbit.com/oauth/authorize");

--Aaron

[JeremiahFitbit]

---

@password1 wrote:

Got an unhelpful email today saying we failed the blackout test because we're making non-https calls. We updated our app months ago and have https everywhere. Not sure why fitbit doesn't give us a list of failed calls or summary.

How can I go about finding what your logs are reporting as non-https?

Or is this just another fitbit bug (like the xml response api calls), and was everyone possibly incorrectly spammed???

---

Hi password1,

First, please take it down a notch. Respectful behavior is obligatory here. We're a small team of real people trying to make sure that all apps have a smooth transition in November for our shared users.

Fitbit handles billions of API requests a month. It's not easy to provide application specific logs. We are working to provide a tool to allow application owners to see any non-HTTPS requests.

[JeremiahFitbit]

Got an unhelpful email today saying we failed the blackout test because we're making non-https calls. We updated our app months ago and have https everywhere. Not sure why fitbit doesn't give us a list of failed calls or summary.

How can I go about finding what your logs are reporting as non-https?

Or is this just another fitbit bug (like the xml response api calls), and was everyone possibly incorrectly spammed???

[JeremiahFitbit · Accepted solution]

To verify if your application is making non-HTTPS requests to the Fitbit API:

1. Go to http://httpschecker-30885.onmodulus.net/
2. Enter your client key from https://dev.fitbit.com
3. If your application had any non-HTTPS Fitbit API requests in the time period noted on the page, they will be displayed.

[password1]

Jeremiah,

Thank you for your team's quick response and tool for checking non-https. So far it confirmed that our code was updated and we're good to go.

I apolagize for the frustrations portrayed in my posting. Our team was more calm with the xml error bug because we understand bugs happen, but it was alarming for us to get an email this time because it contained no specific way to dignose a potentialy dangerous issue any further.

I do understand that you're offering what amounts to a free service, and that there's a lot going on behind the scenes to handle all Consumers. I really appreciate the level of effort of your team to address this issue and turn a solution around a tool so quickly.

Thanks again!

password1