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).
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.
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.
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.
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:
Any other topics you’d like to discuss?
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:
||User copies key/secret from profile page into application
||Application developer registers via site admin, application directs user to authorise the application
||All applications share key/secret
||Applications registered via admin panel
||Users have to regenerate keys and change all existing applications
||Admin revokes application
||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.
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.)