Subscriber Verification Issue

[stevenknox]

Hi,

I have walked through the process of verifying a subscriber endpoint and can get both a 204 and 404 returned when provisioning the correct or incorrect verification code.

When i click verfify however the page just appears to refresh and nothing seems to happy.

Any ideas what i'm missing?

Thanks,

Steven

[stevenknox · Accepted solution]

Figured it out. I was trying to verify the subscription url:

http://myapp.com/api/subcriberendpoint?verify=validcode

Instead of just having the verification at the root of the application itself like:

http://myapp.com/?verify=validcode

Once I made this change the verification passed.

Thanks,

Steven

[JeremiahFitbit]

@stevenknox: The verification should be on the subscriber URL. Is that what you're saying?

[jkingyens]

It sounds like he is saying the verification should be on the root, not the subscriber endpoint. Is this true?

[Qualcee]

1. In my application configuration, my "Application Website" is in the form

http://mydomain.com/myappname/

and my "Endpoint URL" is in this form: 

http://mydomain.com/myappname/fitbit/notify

There is no place in the application management labeled "Subscriber URL" although the Endpoint URL is in the subscriber section.

Does this mean my verification calls will come to:

http://mydomain.com/myappname/fitbit/notify?verify=validVerificationCode

 or

http://mydomain.com?verify=validVerificationCode

2. My endpoint url "type" is set to XML file. The api has stopped accepting calls for xml. Will notification be force to switch to JSON file or JSON body?

[AndrewFitbit]

@Qualcee Checkout the section "Verify a Subscriber" in the docs, that might help. The post from here should cover your second question:

---

JeremiahFitbit wrote:

XML Inaccessible via OAuth 2.0

Fitbit deprecated XML support a year ago. Applications will not be able to request the XML format when using OAuth 2.0. (The specialized XML format TCX remains supported in OAuth 2.0.)

OAuth 1.0a applications requesting XML will need update to use JSON. We recommend switching to JSON resources before upgrading your application to OAuth 2.0.

---

[Qualcee]

I read the docs, that's why I asked. It does not make sense to me that you would call to a uri that could possibly not be accessible. For instance my app runs at a path that is not the root and therfore I can't actually receive the verification if it goes to the root, instead of to the subscriber path. So in fact the documentation might be correct as to what happens, but reaslistically it doesn't help me because I can't verify. My only saving grace is that these applications were registered a couple years ago, before the mandatory verification, but what if I need to add a new endpoint, basically I can't

Also, I understand that API calls are now only JSON, I've already fixed my app to handle this. Since this thread was in regard to subscriber notifications, I didn't think to reinforce that my XML question was in regard to subcription notifications received, not api calls made. The application manager subscription setup part allows us to select XML as the choice, I just want to know if that might go away considering the move to JSON only in the api.

[peterwallhead]

I'm having the same problem, I can't verify my subscriber endpoint url, but haven't yet tried to verify the root url.

[JeremiahFitbit]

The verification is done on the full subscriber URL, not the hostname.

If your subscriber is

https://myapp.com/webhooks/fitbit

the verification requests will look like

https://myapp.com/webhooks/fitbit?verify=8c6f31aeff6d86571fc91707b6b70080c022f8c97ea46938c02331054e32f0fb

[JeremiahFitbit]

If you are having trouble with the verification, use Runscope Traffic Inspector in between Fitbit and your app. This will show you the exact request Fitbit makes to your subscriber and how your application responded.

[sfauerbach]

Thanks for the reply. That's would be a great thing to clarify in the docs.

[peterwallhead]

I've just tested it using Runscope and it passes all 3 tests perfectly (no verify variable = 204, correct verify variable = 204, and wrong verify variable = 404).

Verifiying within the Manage Apps console does not work.

[peterwallhead]

So it turns out that I'm using a Startcom cert which doesn't seem to be supported by Fitbit (http://littlelogs.co/peter/log/4018/#comments)

Can someone from Fitbit please confirm this before I go and pay for a new cert?

[JeremiahFitbit]

It's up to the certificate authority to make sure it is trusted by Oracle and Ubuntu, whose certificate lists we use. It appears that StartCom has failed to do this.

[Balajijana]

I have a doubt whether i can check this for the localhost url. For example localhost:3000/api/fitbit/notify. IS it possible?

[StefanS]

No that won't work - your endpoint needs to be publicly accessible over the Internet. You could use something like DynDNS for verifying a subscriber endpoint that you are hosting locally though (that's what we have done and it works just fine).

[Balajijana]

Hi ,

In my site we are using starfield Services Root Certificate Authority - G2. Does fitbit support for this?