Private Blogs for Fully OAuthed Requests

[John Bunting]

Hey all,

Just wanted to let you know we turned on private blogs and posts for blogs that have sent us a FULLY OAuthed request, meaning you'll see private blogs pop up in the /user/info route and private posts show up. You'll also see private posts show up when you send fully OAuthed requests to the /posts route. 

I know that's been a blocker for many of you and I'm hoping that helps. Official announcement is here: http://developers.tumblr.com/post/29137944541/changelog-for-the-week-of-08-07-12

If you have any issues, suggestions, problems, let me know here, email me, or send an ask to the developers blog. 

Thanks!

-- 

John Bunting

Simplicity is a prerequisite for reliability

   --Edsger W. Dijkstra

[mrjason]

Great stuff. Thanks John and team.

[Oliver Fürniß]

This implies that the state 'private' is back when creating a new blog post (not mentioned in the API documentation)?

[Daniel Jalkut]

Thanks, John. This is encouraging. I did a quick test and would like to point out two observations:

1. Private posts are not showing up for me from the /posts endpoint, even with full OAuth authentication - UNLESS by "FULLY" you mean OAuth credentials obtained separate from the xAuth method. Other folks reading this: have you tried yet and have you been able to read private posts from /posts?

2. I AM able to read a specific private post from /posts if I supply its post ID, however, there is no indication in the post metadata that it is in fact private. This is meaningful to any client that will allow users to alter the state of a post between public and private.

(In general, this is an extension of the failure of Tumblr 2.0 API to identity meaningful characteristics of posts. For instance if you do follow through with the much-desired ability to fetch any post by its ID from /posts, it will still be relatively frustrating if we can't tell that it's a draft, queue, etc., post without pre-knowledge about the post ID).

Daniel

[Daniel Jalkut]

FWIW this has been working for some time, even before the recent changes. So yes, at this point it feels like a documentation bug. Specifying "private=1" in the parameters list for a post will set it to private.

Daniel

[Felix Bonkoski]

Really? In creating a post only, or on editing a post as well?

Golly that sure would be nice, since I had to write a work-around that logs into tumblr with HTTP and spoofs the "Page Edit" in order to mark a post private.

Felix

--

Felix Bonkoski

[Daniel Jalkut]

John - while we're talking about private posts I wanted to mention it would be real nice if Tumblr 2.0 API supported the ability to change a posts state from "published" back to either "private" or "draft". In practice, people make mistakes when publishing posts and in lieu of ability to switch back, they have to delete the post outright, hopefully after copying and pasting the text out into a new post. It would be a more user-friendly behavior, and easier to code user-interfaces to, if the state could be toggled reliably in either direction.

Daniel

On Friday, August 10, 2012 2:59:33 PM UTC-4, John Bunting wrote:

[Daniel Jalkut]

Only for a new post, unfortunately. See my separate plea I just sent :)

[Felix Bonkoski]

Comments

1. No, private *posts* are not showing up here either. I'm not using xAuth, but the credentials obtained through the Web-auth + callback flow.
   
   I think what John was implying was that you could fetch the list of posts from a private blog, if you send appropriate OAuth credentials to the /posts API endpoint.
   
   But this has already been working for some time, so I don't know why the announcement.
   
   
2. IF private *posts* are going to be returned via the /posts endpoint, then we absolutely need a field on the post object telling us it's private, so we can filter those posts accordingly.  If fetching /posts started sending back private posts right this moment, it would break a bunch of my things.
   
   So @JohnBunting, please give us warning if you're going to do this, and tell us how the private posts will be marked.

Felix

--

Felix Bonkoski

[Felix Bonkoski]

On Sat, Aug 11, 2012 at 9:04 AM, Daniel Jalkut <jal...@gmail.com> wrote:

Only for a new post, unfortunately. See my separate plea I just sent :)

 

Ha, naturally.

Well, good thing I wrote that HTTP back door code.

Felix

[Oliver Fürniß]

Thanks Daniel, it is working. But can we be sure that this undocumented option will stay in that awesome V2 API?

[Felix Bonkoski]

On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver....@gmail.com> wrote:

Thanks Daniel, it is working. But can we be sure that this undocumented option will stay in that awesome V2 API?

Personally, I would prefer if marking a post "private" was rolled into the existing "state" parameter sent when creating / editing a post, rather than with this additional parameter "private".

This would be more consistent: each post would be in one of the states (published, draft, queue, private) and you could alter that state consistently with the API.

Felix

[HoLin]

Great Job!

Thank you! John.

I can fetch private blog and the posts of private blog now. 

[John Bunting]

Hey All, 

So I'm going to start this off by what I mean when I say "fully authenticated". We have 2 types of authentication mechanisms on API v2, API Key and OAuth. OAuth is what I'm referring to when I say "fully authenticated", meaning

a complete signed request to our API. It's important to note that you are not getting different access keys from an xAuth or web-flow route. They are both OAuth just with different authentication mechanisms to get the access key magic. 

So now that I have that said, I built some gists to help explain this change better. 

First up is the sample payload of the /user/info request. This route is always a fully authenticated OAuth route.

https://gist.github.com/910729a15878a6382f58

Second up, a sample payload of my test blog with just API Key authentication.

https://gist.github.com/ebce28588036c83127c6

Please note the last post in the above payload is a sound cloud post. 

Third up, the same request but fully authenticated with OAuth to the /posts route of my test blog:

https://gist.github.com/9966cf40a0c6c5d0f518

Note: You will not be able to see my private post on my test blog even if you fully authenticate as you are not a member of my blog.

Finally, you should only be able to see private blogs which you are a member of when you have a fully OAuthed Request. Below is a private blog of mine, and in this example you'll see this is simply an API Key authenticated request.

http://api.tumblr.com/v2/blog/bohnjunting.tumblr.com/posts?api_key=<snip> 

Next, try to sign your request with OAuth. You will still get a 404, as you are not members of that blog. I on the other hand get this result:

https://gist.github.com/a55771107438cd283c1c

Hopefully, that helps clear up questions you all have regarding this particular new feature set. 

@Felix, you're absolutely correct. There needs to be a state or some other indicator now that I'm looking at it. I simply turned on what we did for the iPhone app, making sure different edge cases were taken care of.

Also you guys are correct, I never noticed that how to create a private post wasn't added to the documentation, as well as being able to set things private. Expect a small change log update on Monday :) 

You guys point out something else I can improve on with the change log posts which is example payloads and requests with gists attached to them so we can make sure things like this don't happen again.

-- 

John Bunting

Simplicity is a prerequisite for reliability

   --Edsger W. Dijkstra

[John Bunting]

Hey guys,

Just wanted to give you a quick update. We've added a "state" field on post objects as well as the ability to create posts using the state parameter value "private"

http://developers.tumblr.com/post/29364134332/changelog-for-08-13-12

Thanks!

-- 

John Bunting

Simplicity is a prerequisite for reliability

   --Edsger W. Dijkstra

[Felix Bonkoski]

Awesome, thanks John!

I'll give it a whirl later today.

Felix

--

Felix Bonkoski

[Felix Bonkoski]

@JohnButing, well, it seems you've accomplished about Half of what's needed regarding private posts.

I am still unable to change the state of a "published" post to "private" via the /{hostname}/post/edit  endpoint.

This is a common way for a user to "hide" a post they don't want displayed publicly anymore, without deleting it entirely.

Is this just an oversight?  Or do you only intend these new "state" features to apply when creating posts, not editing them?

Note, for example that I can edit the state of a "draft" post ----> state "queue".  (That's worked for some time.)

Felix

On Mon, Aug 13, 2012 at 5:43 PM, John Bunting <jo...@tumblr.com> wrote:

--

Felix Bonkoski

[John Bunting]

Try it now! You should be able to set a post back and forth from private & published.

You won't be able to set it from published to queued/draft etc. It's going to reflect the options you get when you edit a post on the main site. 

Thanks!

-- 

John Bunting

Simplicity is a prerequisite for reliability

   --Edsger W. Dijkstra

[Felix Bonkoski]

@JohnButing, Awesome. Thank you for fixing that!

Yes obviously published --> queued/draft makes no sense.

Now I don't have to use my awful hacky code that logs a user into Tumblr via tumblr.com/login, & simulates the HTTP session of editing a post. :)

Felix

--

Felix Bonkoski