Solving the 409 Conflict

[EatenByAGrue]

tldr; What should I be doing with the data returned with a 409 Conflict status?

As I attempt to authenticate an account via oAuth I'm getting the 409 Conflict HTTP Status Code. Based on Fiddler, this is my response from FitBit:

<?xml version="1.0" encoding="UTF-8"?><result><collectionType>user</collectionType><ownerId>2G2QQ3</ownerId><ownerType>user</ownerType><subscriberId>1</subscriberId><subscriptionId>ec368ceb6edd41fc901a60090ac17a6e-user</subscriptionId></result>

According to the docs here:

https://wiki.fitbit.com/display/API/Fitbit+Subscriptions+API#FitbitSubscriptionsAPI-Addasubscription

this XML response contains the information I need to fix the data on my end.

When I receive the 409, I save out the data in the same manner as I would if I had received a 200 or some other success code, as it has the Owner ID and Subscription ID -- which are supposedly the pieces of data I need to be using (as per docs, above). However, when I follow this up with an attempt to un-authenticate, I get a 404 error. If I go back to authenticate again, I get the same 409 as before.

So, long story short, what should I be doing with the data returned with a 409 error?

I didn't write our original authentication code and am not entirely familiar with what all needs to happen with FitBit's oAuth process, so please forgive me if I'm asking a stupid question.

[ibahdanau]

Basically what this response it telling you that either subscription with id == [ec368ceb6edd41fc901a60090ac17a6e-user] already exists or you have already subscribed to listen for that type of events <collectionType>user</collectionType><ownerId>2G2QQ3</ownerId>, so there is no need to subscribe for second time. 

[EatenByAGrue]

If that is the case, then I would think that I could just proceed with the values as returned with the 409. But then shouldn't I be able to deauthorize without a 404 (not found), and then reauthorize without another 409 conflict? According to the API documentation, deauthorization with a 404:

if the given subscription ID did not exist for this application (for example, if your application already unsubscribed)

If I'm getting a 404 when I try to deauthorize based on the data returned from a 409, then I would think the data in the 409 is incorrect, or that I must do something more tricky than just treat the 409 data as I would were the server to have returned a 200 Success.

[ibahdanau]

Please provide exact API urls and parameters that you pass to add subscription and remove subscription.

[EatenByAGrue]

Add subscription:

me: https://api.fitbit.com/oauth/request_token
Fitbit: oauth_token=d5385fa8d10948709c7c0390372d7314&oauth_token_secret=904df06d2728b15a094fd12657a91fca&oauth_callback_confirmed=true

me: https://www.fitbit.com/oauth/authorize?oauth_token=d5385fa8d10948709c7c0390372d7314
Fitbit: (HTML for the authorization page)

me: https://www.fitbit.com/oauth?oauth_token=d5385fa8d10948709c7c0390372d7314&locale=&display=&authentic... HTTP/1.1
Fitbit: (HTML for the authorization page)

// this is just our callback from Fitbit

me: http://localhost:60969/sync/callback/1?oauth_token=d5385fa8d10948709c7c0390372d7314&oauth_verifier=trc8mjakmljg70d116f6cnn77m

me: https://api.fitbit.com/oauth/access_token
Fitbit: oauth_token=1a22e5a1f6e0cde82fb161fc7135d466&oauth_token_secret=418b55de9a4d52422945a86bce2c77c8&encoded_user_id=2G2QQ3

// this is the one with the 409 Conflict

me: https://api.fitbit.com/1/user/-/apiSubscriptions/a69fb694d3414e5cb9509ad147a4bf49-user.xml
Fitbit: <?xml version="1.0" encoding="UTF-8"?><result><collectionType>user</collectionType><ownerId>2G2QQ3</ownerId><ownerType>user</ownerType><subscriberId>1</subscriberId><subscriptionId>ec368ceb6edd41fc901a60090ac17a6e-user</subscriptionId></result>

Remove Subscription:

// this comes back with a 404

me: https://api.fitbit.com/1/user/-/apiSubscriptions/a69fb694d3414e5cb9509ad147a4bf49-user.xml
Fitbit: <?xml version="1.0" encoding="UTF-8"?><result></result>

Thanks for your help! 

[EatenByAGrue]

Anyone? Suggestions?

Is Fitbit returning valid values to me?

Is Fitbit handling this as expected?

I just take the subscriberId and ownerId returned by the 409 and treat it exactly as I would if the server returned a 200 with the same data -- is this not correct? And if it is correct, have I done something incorrect when I unsubscribe?

[IoanbsuFitbit]

___

[ibahdanau]

Did you change anyhow token values or secrets before pasting them in you previous message?

I'm trying to look it up and not finding anything.

Please copy and paste your current customer token(from you app info at dev.fitbit.com) and send me it in private message.

Please do not reset your customer key for awhile once you send it to me so I'll have time to look it up.

[EatenByAGrue]

Keys have been sent.

I did not change the values communicated over https (oauth_token, oauth_token_secret), as I believed these values to be useless to anyone else.

I have tried to authenticate with this account a few more times since this log, so I do not know if the values you are looking for have been lost in your database or not. I would be happy to attempt to authenticate again if that would help.

[ibahdanau]

Hm, interesting. I just checked and it seems that your application have no subscriptions to user 2G2QQ3.

 So that means that conflicted subscription had been removed.

Can you please go ahead and try to add subscription again and please send to me your request with headers and response from Fitbit API in private message in case you get the same error.

[EatenByAGrue]

Sent 🙂