No meeting this week, due to Easter holidays, however I’ll be around for office hours on Friday, 0:00 UTC instead.
I’ve published the OAuth server work so far. This is probably broken, but that’s OK, because at least it’s a start. :)
Of particular note is the specification, which I’d appreciate thoughts on. This is intentionally kept as simple as possible, since it’s mostly standard OAuth 1.0a.
I’d especially love feedback on the scopes section of the document. I think this lays out a general set of scopes that cover most use cases, and anything that needs more complicated permissions can fall back to the general
* permission. I’m not sure yet whether defaulting to
* is the right idea; we may want to default to
In case you missed it, version 0.9 was finally released. Sorry for taking so long on that one, and thanks to everyone who helped with this release (nine contributors!).
OAuth as a Plugin
I’m splitting the OAuth support into a separate plugin. We need to get ready for merge into core, and we can’t be blocked on OAuth support. The current plan is to ship WP API in 4.0, and OAuth in 4.0 if it’s ready or a future release if not. Nonce-based authentication needs to ship in 4.0, so that we can start creating API-powered plugins and themes.
I’m working on extracting this out into something usable at the moment, I’ll update when this is available. I’d also like to approach the possibility of adding permission scopes since it’s now separate, so I’m working on preliminary support for this too.
Meeting Time Change
Seeing as the meeting time is going to change for anyone who’s recently switched from/to DST, I’d like to move the meeting time to a time that works better for me. I’d like to propose Tuesday, 0:00 UTC (01:00 BST, 10:00 AEST, Monday 20:00 EDT, Monday 17:00 PDT). This time is likely a little worse for some of you, but I’ll be able to consistently be available at this time. In future, we’ll start with a meeting and continue with office hours for the remainder of the time, during which I’ll be working exclusively on the API.
On that note, our next meeting will be this Tuesday. I’d like to discuss the OAuth plans, 1.0 and @iandunn‘s CPT privacy issues. Feel free to propose any other items of importance; otherwise, see you all there! :)
I’ve been auditing the data that is exposed by default by the API, and I’ve run across several instances where sensitive data is shown to anonymous clients. In each case, this was caused by a plugin creating custom post types with posts and meta fields set to `public` rather than `private`.
I think the potential ramifications for this are pretty huge. For example, I was able to anonymously read contact form submissions from Jetpack, because those use a custom post type. The post type is set to `private`, but the posts themselves are set to `publish`.
I was also able to read threads in private bbPress forums for the same reason, as well as sensitive data stored in post meta fields on various custom post types, because they weren’t marked as private with the `_` prefix (or the `is_protected_meta` filter).
I think the vast majority of plugins using custom post types are flawed in the same way, because up until now there haven’t been any hard consequences for improperly setting the `public` flag on a post type, or for `publishing` posts that have no front-end archive, or failing to set meta fields to private.
I think this begs a lot of questions around privacy and the expectations of site admins and plugin developers, and I wanted to start a discussion around those.
- Should the onus for privacy be on the API, on plugin developers, or on site admins? I think the answer to this question will shape how many of the other questions are framed and answered.
- Should the API be enabled by default?
- Should all “public” data be exposed by default, or should the admin have to whitelist the data they want exposed?
- Should `published` posts belonging to a `private` post type be exposed?
- Should there be a new flag added to `create_post_type()` to indicate whether or not a post type and it’s associated posts/meta are included in JSON API output?
- Some post authors will manually create custom fields on a post to store notes, and they won’t know anything about using the `_` prefix to make it private. How can that situation be handled?
- Do new best practices need to be developed around privacy and custom post types, and then spread out to developers? For instance, sending an email to every plugin author in repo who calls `create_post_type()`
Thanks to everyone who’s been helping out with 0.9, we’re down to just OAuth (and a smaller issue that needs a patch that does the opposite of the current one). Huge thanks to @ibaku for his work on the testing framework, and @rachelbaker for her help merging and triaging along with everything else.
I’d like to get more eyes and testing on the OAuth code before calling it final though. This has been sitting on my computer for a while, but still needs serious testing and more eyes before we can call it ready. I’d also love to hear thoughts on the approach in general too.
Aiming for 0.9 release this Friday. More posts to come during the week as we reach that, and scope for 1.0.
Hi everyone! Apologies for the long hiatus. Let’s get back into it!
Good news: I have a plan for authentication, and it’s time to start implementing it! Here’s the plan:
- OAuth 1.0a: All remote consumers will need to use OAuth 1.0a to access the API.
- OAuth Dynamic Registration: New consumers will be able to register via the dynamic registration protocol. The OAUTHWG is in the process of working on this and seems to be making good progress, so it should be ready for a V2 of the API.
- Cookie authentication: For local (JS-based) clients, they’ll be able to leverage the existing cookie authentication in conjunction with a CSRF token.
Hopefully, this plan covers all the cases. In an ideal world, we’d be using OAuth 2.0 instead, but alas we can’t. I’m not sure exactly how much of the OAuth dynamic registration protocol we’ll have to adapt to OAuth 1.0, but in any case we’re better off adapting the protocol they’re working on, rather than reinventing from scratch.
The other big ticket item we need to handle is unit testing. @ibaku has made a great start on this, but we need tests to cover the rest of the API. I’d like to end up with >90% coverage eventually, but that’s a long-term plan. For anyone who wants to start contributing patches, this is a great place to start, since you can work in a modular way and learn the API as you go.
I’d like to set the timeline for our next release for next Friday. I think we should be able to get a pull request up for every issue in that time. I’ll start merging the existing pull requests from tomorrow. I could use help triaging the non-triaged issues if anyone has time!
Let’s also start getting into meetings again. Let’s go for next week, Monday 17th at 21:00 UTC (Tuesday 18th at 07:00 AEST, Monday 17th at 16:00 EST, Monday 17th at 13:00 PST). We can discuss the plans for 0.9 and progress towards it.
Boom. Let’s rock it.
Also, as always, we’ve got the meeting this week on Monday 16th at 21:00 UTC (Tuesday 17th at 07:00 AEST, Monday 16th at 16:00 EST, Monday 16th at 13:00 PST).
There’s nothing in particular I’d like to discuss this week, but I’ll be around for a few hours anyway. More than anything else, we just need to focus on getting all the tickets resolved for 0.9 and 1.0. If anyone wants to take a stab at anything, I’m happy to work with you on getting it done.
We’ll be skipping next week’s meeting over the Christmas break, and the meeting afterwards will be on Monday 30th (which hopefully shouldn’t conflict with anyone’s New Years plans).