|Serious failures with V1 Tumblr API||Daniel Jalkut||7/18/12 6:31 AM|
Customers who use my Mac blogging app, MarsEdit, are reporting widespread failures logging in and refreshing posts on their Tumblr blogs. The implications of this failure are widespread and affect all of my customers who use Tumblr, as well as the customers of many other clients of the API. Thanks for your consideration in repairing the behavior of the API as soon as possible.
I have traced the problem to at least one major failure in the API, where it is now rejecting credentials when asking for draft posts:
Network reply received: 2012-07-18 13:26:19 +0000
Method name: POST
Status code: 403
Fault code: 403
Fault string: Authentication required.
At least some authenticated requests are still working, for example, with the exact same credentials, I am able to submit a new post and delete a post:
Network reply received: 2012-07-18 13:27:01 +0000
Method name: POST
Status code: 200
Hope this helps,
|Re: Serious failures with V1 Tumblr API||John Bunting||7/18/12 6:35 AM|
We're looking into it.
Simplicity is a prerequisite for reliability
--Edsger W. Dijkstra
|Re: Serious failures with V1 Tumblr API||Daniel Jalkut||7/18/12 6:36 AM|
Thank you, John!
|Re: Serious failures with V1 Tumblr API||John Bunting||7/18/12 6:40 AM|
Can you try sending your parameters in the body of the request and not as request params?
|Re: Serious failures with V1 Tumblr API||Daniel Jalkut||7/18/12 6:48 AM|
Aha - you are probably on to something there. It does seem like the API calls that I happen to put parameters in the body are the ones that "still work." It will take me a few minutes to switch my getPosts code to using body parameters, but I will try that to confirm.
I am happy to switch to using body parameters if that is the preferred method, but if possible it would still be great to restore the previous behavior, because existing customers will need to wait for an updated version of MarsEdit which, especially for Mac App Store customers, can involve quite a delay.
|Re: Serious failures with V1 Tumblr API||John Bunting||7/18/12 6:49 AM|
Yeah, We did this because we saw people sending passwords in the request parameters as part of legacy code (v1 way before my time) I figured it wouldn't break anyone. Hah.
OK let me talk about restoring the old functionality and giving you guys a countdown until we phase it out. Probably 2 weeks. Does that sound sane?
|Re: Serious failures with V1 Tumblr API||Daniel Jalkut||7/18/12 6:57 AM|
Maybe I'm missing something but if the connection is over HTTP then isn't the password in the body of the request just as exposed as the password in the request URL? I don't think there is a security improvement here by requiring the parameters to be in the body.
I agree that the authentication scheme in V1 is less desirable than the V2 OAuth approach. I intend to update to that API when I can, but in the mean time as there has been no indication the V1 API is going away or changing, I think it would be a mistake to pull the plug on any of its behaviors without significant advanced warning.
As far as advance warning, twoweeks would obviously be better than no time at all, but it still feels quite rushed especially if there is no actual security improvement with the required changes. For a serious transition like this I would imagine most developers would expect a transition phase on the order of months, not weeks.
Thanks for looking into this so quickly,
|Re: Serious failures with V1 Tumblr API||Daniel Jalkut||7/18/12 8:40 AM|
John - I am working on switching my /read calls to pass parameters in the body of the request, but I want to let you know about some serious problems with that, which probably explain why I'm using the URL form for passing parameters in the first place.
It looks like the URL will ignore most parameters in the body. For example, if I try to ask for a specific id, or ask for only posts of draft format, it just returns the regular list of posts. Similarly, the start offset is ignored, so paging requests of posts is impossible.
I'm going to assume that NO parameters to /read should be put into the body of the post except for the authentication parameters.
Seeing as how the parameters in the body are ignored, it seems safe to assume that ALL clients who are currently using the V1 API are in fact passing parameters in the URL and not in the body of the request. Thus probably all V1 clients who use /read are affected by this issue.
WIll you please consider restoring the old behavior at least until you have a chance to consider the implications on clients? My support inbox is starting to ramp up with inquiries from affected customers.
|Re: Serious failures with V1 Tumblr API||Daniel Jalkut||7/18/12 9:01 AM|
Hmm - even worse. I think that the email and password are not respected in the body of the POST request for /read, either.
In short: I think that /read *requires* that all parameters be passed in the URL.
I cancelled a submitted version of MarsEdit from the App Store, because I wanted to sneak in whatever fixes are necessary to keep it working with Tumblr. At this point though, I don't know enough to definitively fix it. Given the current broken state I am hoping you will flip things back to the way they were so we can hash out how to best move forward with improved password handling.