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.

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.

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.

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.