Serious failures with V1 Tumblr API

438 views
Skip to first unread message

Daniel Jalkut

unread,
Jul 18, 2012, 9:31:05 AM7/18/12
to tumbl...@googlegroups.com
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
Succeeded: NO
--Fault Error--
Fault code: 403
Fault string: Authentication required.
Response text:
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
Succeeded: YES
Request text:
email=[email]&password=[password]&post-id=27445014266

Response text:
Deleted

Hope this helps,

Daniel

John Bunting

unread,
Jul 18, 2012, 9:35:45 AM7/18/12
to tumbl...@googlegroups.com
We're looking into it.

-- 
John Bunting

Simplicity is a prerequisite for reliability
   --Edsger W. Dijkstra

Daniel Jalkut

unread,
Jul 18, 2012, 9:36:19 AM7/18/12
to tumbl...@googlegroups.com
Thank you, John!

John Bunting

unread,
Jul 18, 2012, 9:40:16 AM7/18/12
to tumbl...@googlegroups.com
Can you try sending your parameters in the body of the request and not as request params?

-- 
John Bunting

Simplicity is a prerequisite for reliability
   --Edsger W. Dijkstra

On Wednesday, July 18, 2012 at 9:31 AM, Daniel Jalkut wrote:

Daniel Jalkut

unread,
Jul 18, 2012, 9:48:17 AM7/18/12
to tumbl...@googlegroups.com
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.

Daniel

John Bunting

unread,
Jul 18, 2012, 9:49:39 AM7/18/12
to tumbl...@googlegroups.com
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?

-- 
John Bunting

Simplicity is a prerequisite for reliability
   --Edsger W. Dijkstra

Daniel Jalkut

unread,
Jul 18, 2012, 9:57:01 AM7/18/12
to tumbl...@googlegroups.com
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,
Daniel

Daniel Jalkut

unread,
Jul 18, 2012, 11:40:14 AM7/18/12
to tumbl...@googlegroups.com
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.

Daniel

Daniel Jalkut

unread,
Jul 18, 2012, 12:01:43 PM7/18/12
to tumbl...@googlegroups.com
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.

Daniel
Reply all
Reply to author
Forward
0 new messages