Ryan McCue 12:12 on April 12, 2014

Hi everybody! In case you…

Hi everybody!

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! 🙂

Ryan McCue 14:08 on March 5, 2014

Thanks to everyone who’s been…

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.

Ryan McCue 13:11 on February 10, 2014

Hi everyone! Apologies for the…

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.

Ryan McCue 01:41 on December 15, 2013
Tags: meeting

Also, as always, we’ve got…

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).

#meeting

Ryan McCue 01:34 on December 15, 2013

In case you missed it,…

In case you missed it, version 0.8 is out, albeit a little late. I also didn’t get around to posting the meeting notes from last week, so here’s a quick roundup:

One Consumer Per User vs Independent Consumers / Consumer Registration
We’re going to go with independent consumers, because we kind of have to. The conversation turned to how we register new consumers, and a number of interesting ideas were floated: creating a central repository on WP.org where consumers like mobile apps can register, for example. We’re going to circle back around to both this and scoped tokens after we get the initial OAuth stuff settled.

Multisite
In order to load the correct plugins, we’re probably going to have to go with per-domain API endpoints (e.g. wpapiteam.wordpress.com/wp-json.php). nacin pointed out that we could hack around to avoid this in ms-settings.php, but it’s a bad idea. Whatever we use here is going to be a compromise, and this seems like the best one. Also worth mentioning that we have a multisite-specific plugin that needs some serious love.

This Week
I’d like to push out two releases this week so that we hit 1.0 before Christmas. The plan currently is 0.9 on Tuesday (post-meeting) and 1.0 on Saturday. We’ve got a few issues that still need pull requests before 0.9. Importantly, I really want to get tests happening this week, either in 0.9 or 1.0, as we really need them. We’ve already been bitten by a compatibility issue.

We also need to land authentication this week. The initial version that I’m working on has no UI at all, but follows the independent consumer model as discussed. The UI we can work on later, after we ensure that the authentication works properly.

Ryan McCue 04:10 on December 9, 2013

The meeting this week is…

The meeting this week is coming up in ~17 hours (Monday 9th at 21:00 UTC, Tuesday 10th at 07:00 AEST, Monday 9th at 16:00 EST, Monday 9th at 13:00 PST). Here’s what I’d like to discuss:

One consumer per user vs independent consumers
New API consumer registration
Multisite: single API vs separate APIs (feedback from @justin for WP.com appreciated here)

Any other topics you’d like to discuss?

Ryan McCue 06:39 on December 8, 2013

I’ve been messing around with…

I’ve been messing around with the WooCommerce code for OAuth, and unfortunately it has API consumers (that is, applications) tied to users. This is a pretty limited method, but it simplifies the code and flow a lot. The question is, do we want core to be limited to this extent, or do we need to think about something more complicated? With this sort of flow, we can show the user’s API key/secret on their profile page, and they just need to fill that in to their application. (We could also add an xAuth flow, where the application can request those keys via Basic authentication.)

Alternatively, we treat consumers as an entirely separate entity, which can then prompt users to authorise them. This is the more traditional OAuth flow that you see with Twitter, Facebook, etc. This increases the application complexity a bit, but allows a site admin to manage applications rather than having it managed per-user. It also allows “rogue” (misbehaving/compromised) application keys to be revoked, rather than requiring each user to regenerate a key/secret.

I’m on the fence about this one. There are benefits to both approaches, and I’ve summarised these below:

	One-consumer-per-user	Independent consumers
Setting up	User copies key/secret from profile page into application	Application developer registers via site admin, application directs user to authorise the application
Managing	All applications share key/secret	Applications registered via admin panel
Revoking	Users have to regenerate keys and change all existing applications	Admin revokes application
Site UI	Key/secret fields on user profile page	Consumer management settings page

If you can think of any other points here, post in the comments. I think it’s fairly split between the two at the moment, so I can’t really decide.

Ryan McCue 13:29 on December 3, 2013

I’ve put up an anonymous…

I’ve put up an anonymous feedback form on Google Docs. If you have anything to say about the project, the team, project management or anything else, please use it. Feel free to suggest new features there as well. This is a resource for everyone to use, no matter how involved you are with the project.

Regardless of whether you’ve been involved with WordPress for a long time or you’re a newcomer, regardless of how proficient you think you are, you have something to contribute to the project. There’s nothing worse from my perspective than seeing people discuss issues on other forums that I didn’t even know existed, then hearing that they didn’t think their feedback would be taken seriously or they didn’t think it was worth submitting. There’s nothing I’d love more than to wake up tomorrow with tonnes of new emails in my inbox.

If you’re reading this post, please, go and submit a piece of feedback, even if you think you have nothing to say. Anything from a single sentence all the way up to an essay is welcome.

(For those that are interested, Google Docs stores the results in a spreadsheet. The only data gathered apart from what you supply is a timestamp of when you submitted the form.)

Ryan McCue 22:38 on December 2, 2013

Meeting notes from today, for…

Meeting notes from today, for those who missed it (see also the IRC logs):

Response Objects (#33)
Response objects are on their way. Discussed how we handle WP_Error and whether we should implement a WP_JSON_Error. I’m in favour of the former, since it’s an existing paradigm in WP core, but WP_JSON_Error being a Response object would be nice. We’re going to loop back to this after the response object is merged.

User Endpoints (#20)
We’re going with read-only access for now, since the code is basically already written (for post authors). Write access will be established later, but this is a pretty low priority for now unless anyone wants to tackle it specifically.

Endpoints vs Routes vs ?
@mikeschinkel pointed out that the terminology here is a little confusing, since the permalink system has a concept of endpoints too. As it relates to the API though:

endpoint = code which supplies a response, route = map from HTTP to endpoint

We’ll probably want to revisit this for core merge and clarify it, but this matches the wider API community terminology.

Unit Testing (#6)
Strong consensus here that we need help setting up the infrastructure for unit testing. @ibaku might be able to help us out with this, otherwise I’m sending out the Batsignal to scribu and wonderboymusic to see if they can give us some pointers (as they both have familiarity with testing).

Theme Developers and Outreach
@rachelbaker pointed out that I didn’t really say how theme developers can help out, so I clarified:

Right, so WP API has a built-in JS API. I’d love for theme devs to take a look at that and see what it’s like using it in the wild
I know Tareq Hasan has written a proof-of-concept one: http://tareq.wedevs.com/2013/09/backbone-js-powered-proof-of-concept-wordpress-theme/
I want to make sure wp-api.js is useful, and flesh it out with more methods as needed

@mzaweb noted we should see if the o2 team has any thoughts on this side of things, so hopefully @justin can help us with talking to them? Also noted that we should talk to the mobile team and get feedback from them, as well as the security team (in particular, mdawaffe) for feedback about authentication.

In short, lots of things to think about. This week’s release is all about OAuth (#32) and I’ll be pushing code up today for that, so we can start testing it. The OAuth stuff will be far from final, so feedback appreciated there too. Basic auth isn’t going anywhere just yet (#37 is scheduled for 1.0), so you can keep testing with that for now.

Ryan McCue 13:27 on December 2, 2013

Just realised I forgot to…

Just realised I forgot to post this earlier, so apologies for the late notice. Just confirming, this week’s meeting is coming up in about 7 hours: Monday 2nd at 21:00 UTC (same time as always). There’s a few things I’d like to touch on, including: