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.
> 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.
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).
On Friday, August 10, 2012 2:59:33 PM UTC-4, John Bunting wrote:
> 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.
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.
On Saturday, August 11, 2012 2:46:19 AM UTC-4, Oliver Fürniß wrote:
> This implies that the state 'private' is back when creating a new blog > post (not mentioned in the API documentation)?
> Am Freitag, 10. August 2012 20:59:33 UTC+2 schrieb 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.
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.
On Sat, Aug 11, 2012 at 8:52 AM, Daniel Jalkut <jal...@gmail.com> wrote:
> 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
> On Saturday, August 11, 2012 2:46:19 AM UTC-4, Oliver Fürniß wrote:
>> This implies that the state 'private' is back when creating a new blog
>> post (not mentioned in the API documentation)?
>> Am Freitag, 10. August 2012 20:59:33 UTC+2 schrieb 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.
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.
On Friday, August 10, 2012 2:59:33 PM UTC-4, John Bunting wrote:
> 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.
On Saturday, August 11, 2012 10:00:56 AM UTC-4, felix bonkoski wrote:
> 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.
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.
On Sat, Aug 11, 2012 at 8:48 AM, Daniel Jalkut <jal...@gmail.com> wrote:
> 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
> On Friday, August 10, 2012 2:59:33 PM UTC-4, John Bunting wrote:
>> 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.
> 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
> On Saturday, August 11, 2012 2:46:19 AM UTC-4, Oliver Fürniß wrote:
>> This implies that the state 'private' is back when creating a new blog >> post (not mentioned in the API documentation)?
>> Am Freitag, 10. August 2012 20:59:33 UTC+2 schrieb 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.
On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@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.
On Saturday, August 11, 2012 2:59:33 AM UTC+8, John Bunting wrote:
> 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.
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.
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.
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
On Saturday, August 11, 2012 at 10:30 AM, Felix Bonkoski wrote:
> On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@gmail.com (mailto:oliver.fuern...@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.
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"
On Saturday, August 11, 2012 at 11:52 AM, John Bunting wrote:
> 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.
> 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.
> 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
> On Saturday, August 11, 2012 at 10:30 AM, Felix Bonkoski wrote:
> > On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@gmail.com (mailto:oliver.fuern...@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.
On Mon, Aug 13, 2012 at 5:43 PM, John Bunting <jo...@tumblr.com> wrote:
> 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"
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Saturday, August 11, 2012 at 11:52 AM, John Bunting wrote:
> 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.
> *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.
> 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
> On Saturday, August 11, 2012 at 10:30 AM, Felix Bonkoski wrote:
> On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@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.
On Mon, Aug 13, 2012 at 5:43 PM, John Bunting <jo...@tumblr.com> wrote:
> 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"
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Saturday, August 11, 2012 at 11:52 AM, John Bunting wrote:
> 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.
> *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.
> 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
> On Saturday, August 11, 2012 at 10:30 AM, Felix Bonkoski wrote:
> On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@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.
On Tuesday, August 14, 2012 at 11:56 PM, Felix Bonkoski wrote:
> @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 (mailto:jo...@tumblr.com)> wrote:
> > 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"
> > Simplicity is a prerequisite for reliability
> > --Edsger W. Dijkstra
> > On Saturday, August 11, 2012 at 11:52 AM, John Bunting wrote:
> > > 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.
> > > 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.
> > > 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
> > > On Saturday, August 11, 2012 at 10:30 AM, Felix Bonkoski wrote:
> > > > On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@gmail.com (mailto:oliver.fuern...@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.
On Wed, Aug 15, 2012 at 4:22 PM, John Bunting <jo...@tumblr.com> wrote:
> 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
> On Tuesday, August 14, 2012 at 11:56 PM, Felix Bonkoski wrote:
> @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:
> 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"
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Saturday, August 11, 2012 at 11:52 AM, John Bunting wrote:
> 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.
> *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.
> 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
> On Saturday, August 11, 2012 at 10:30 AM, Felix Bonkoski wrote:
> On Sat, Aug 11, 2012 at 9:19 AM, Oliver Fürniß <oliver.fuern...@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.
