On Core REST API Authentication

Having an API is well and good, but if there are no ways for third-party apps to actually authenticate and use the API, it’s not very useful.

Background

While the framework for the REST API was merged into WordPress Core with the 4.4 release, the only means of using any endpoints that currently require authentication are what is known as ‘cookie authentication’ — that is, piggybacking off of the authentication cookies (plus a nonce) that WordPress Core sets in the browser when you log in traditionally to your WordPress site.  Unfortunately, that leaves the REST API as little more useful than the legacy `admin-ajax.php` file.

Fortunately, there are several authentication methods being worked on at the moment, in plugin form, for consideration of merging in to Core.

I’m heading up one of them, called Application Passwords.  In short, it lets a user generate as many single-application passwords as desired — one for each phone, desktop app, or other integration desired — and later revoke any application password whenever desired without affecting other applications or the user’s normal authentication.  The passwords are then passed with each request as Basic Authentication, encoded in the header of each request, as per RFC2617.

The other plugin is OAuth 1.0a authentication (spec).  Most OAuth usage across the internet is actually OAuth 2.0 — however, OAuth 2.0 requires HTTPS on the server side.  Ordinarily for most hosted services, this is not a problem.  However, for a distributed platform like WordPress, this is untenable due to the majority of sites not supporting HTTPS.  So an older, more complex specification — designed to not require HTTPS — had to be used.

For the record, I’m fully expecting to see an OAuth 2.0 plugin be built in the near future for use on sites that have a SSL certificate and support HTTPS.  However, that may not be very useful for app developers that want a ‘build once, run everywhere’ authentication method that will always be available.

Limiting Permissions

One of the discussions that came up with regard to Application Passwords is whether a REST API request that uses Application Password authentication should be able to modify Application Password endpoints.

Now, this is a very interesting question, and it can lead to many more questions — such as if an Application Password shouldn’t be usable to create or delete other Application Passwords, whether they should be allowed to do other user-administrative tasks (providing the relevant user has those permissions).  After all, if we’re preventing them from making a new Application Password, but they can just go and change the user’s actual password or email address, it’s a rather silly restriction.

So, there are several possiblilities.

First, you can just say “Any ways in to your account give full access to everything your account can do.  Be careful what applications and websites you give access to.” — the most basic, relatively easy to understand way.  Honestly, this is my preference.

Secondly, when creating a new Application Password or connecting a new client via oAuth, you could do something like … selecting what ‘role’ you’d like to give that connection.  For example, if your normal user account as an Administrator, but you’re connecting an app that’s intended just for writing blog posts, you may want to downscale your role for that authentication key to either an Author or perhaps an Editor.  An advantage to this is that it would be more cross-API — that is, it would work just as well with the legacy XML-RPC API, as with the new REST API.

This ‘role restriction’ method may be somewhat fragile, as it would need to only filter `current_user_can` and `user_can` — but only when checking the current user’s ID.  However, that may goof up some cron tasks that may run on the same request as the REST API request or other incendtal things.

Thirdly, we could do something REST API specific — either whitelist or blacklist REST API endpoints based on authentication key.  So, when either creating a new Application Password or authorizing a new OAuth connection, you would set rules as to what endpoints it can be used to hit.  Perhaps you’d want to allow all `wp/v2` namespaced endpoints, but no endpoints added by plugins to custom namespaces.  Or you want to only allow it to access core `posts` and `taxonomies` endpoints.  Or even something like allowing it to access anything but `plugins`, `themes`, `users`, or `options` endpoints.

The downside of this is that it won’t work with the legacy XML-RPC API and the user interface for it would likely be far more confusing for users.  It also could get problematic as permissions may vary for who can read `options` endpoints and who can write to them — or the like.  So then it may further complicate to allowing GET requests but not POST, PUT, DELETE requests to certain endpoints.

Your Thoughts?

In the end, I’m not sure what the best path forward is.  Maybe I’ve missed something.  But I am confident that we need to start paying more attention to authentication and permissions for the forthcoming REST API.  If you have any thoughts or remarks, please leave them in the comments.

 

 

Dancing to a Calypso Beat

Sidenote: I wrote this article two months back, at WordCamp US, and am only now getting around to posting it. Sorry for the delay.

A few months ago, the culmination of nearly two years of internal work was open-sourced to the world. A new WordPress admin interface built by Automattic on top of Javascript technologies like Node.js and React, codenamed Calypso.

A lot of folks got excited and a few got scared. Some folks got a bit confused. But I haven’t heard many folks drawing the parallel and writing the explanation that I’ve cobbled together, so here’s my take on it:

For a while now, there’s been a variety of WordPress apps — iOS, Android, and some defunct ones for Blackberry, Windows Phone, WebOS, and the like. They all interact with WordPress via the existing XML-RPC API. They’re not really extensible for plugins — if someone installs “The Events Calendar,” events don’t start showing up in the app as they would in your traditionally PHP-generated WordPress Admin UI.

Calypso currently mirrors those mobile apps more than anything else, just shifted to a wholly different space. Instead of using the legacy XML-RPC API, which is meant primarily as a way to publish content and has a host of issues (sending user passwords in plaintext with every request, for one), it uses a REST API with far better authentication. Instead of running on mobile devices, it runs either in your web browser at WordPress.com or encapsulated in a Desktop app. But at its core, it’s a self-contained administrative application for WordPress sites.

I feel that the biggest win in releasing the Calypso interface, though, is that it can remedy a situation that’s festered for some time now. The current WordPress mobile apps are maintained by a crew of mobile developers that work for Automattic.

Development happens in the open, and community contributions are welcomed, but they are comparatively few and far between — largely due to the fact that the majority of folks who are really passionate about WordPress are primarily familiar with the languages that WordPress is written in — PHP, CSS, Javascript, MySQL, etc. Very few have much interest in leaping into App development. Likewise, most mobile developers have their own set of problems that they are passionate about solving, and volunteering their free time to build and maintain an administrative app for WordPress would ordinarily be low on their list of priorities.

So, it falls to someone to find and hire Mobile developers to maintain the assorted WordPress mobile apps.

With the release of Calypso, though, there is a bit of a paradigm shift. Calypso, being written in Javascript, is already in the skill set of many of the folks who are already passionate about building the core software, as well as those that leverage WordPress to build sites.

This, I think, will mean a significant renaissance of community interest in API-driven apps for maintaining a WordPress site. I also predict that we’ll see a lot of folks passionate about WordPress forking Calypso and tweaking it to make customized apps and distributions for specific clients and use cases — which will only expand further once REST API endpoints ship in WordPress Core, and Calypso migrates to use those, instead of the WordPress.com REST API.

Two-Factor in the Real World

I’m locked out of my Apple account.

I know my password. I still have my cell phone number that is set as a recovery number.

So how could I be locked out?

Several months back, I changed my cell carrier to Project Fi — the Google amalgamation of T-Mobile, Sprint, and WiFi networks to provide better coverage at lower cost. I’ve been thrilled with the service (like, seriously ecstatic), but there are some odd issues that have cropped up.

For one, it seems that text messages from SMS ‘short codes‘ don’t go through.  This has been a known issue for some time now with Project Fi. I first found out about it when trying to set up Google Wallet with USAA — which runs through an automated SMS short codes system. Many automated texts do work without issue — Dropbox, for one.

At this point, it should be noted that Project Fi is not listed on the list of carriers that Apple officially supports for sending out two-factor login codes.

So I just spent a full hour (I clocked it at the end) on the phone with a very empathetic and understand customer service rep from Apple.  Unfortunately:

  • I don’t have any iOS or OSX devices currently logged into my iCloud account (I had just voluntarily switched my primary computer to Windows for work)
  • I can’t receive txt messages from their automated system at the phone number I have on file (despite the fact that I called them from that number and they can call me back at that same number)
  • I don’t have my recovery key (it was about three years back when I first turned on two-factor authentication, and I have absolutely no idea where I would have stored it)

So there is absolutely nothing that they can do for me, it seems.

I mean, I understand this to a point. The rep I had on the phone was very apologetic, but the system that they built just doesn’t account for the fact that perhaps sometimes phone numbers lose the ability to receive text messages.

They knew I was who I said I was — I was calling from my number on file, I had all my credit card information, I could authenticate the first step of logging in.  They could even call me at the phone number they have on file.  But because they couldn’t text me, they couldn’t — not wouldn’t, but actually couldn’t — help me.

But this isn’t meant to be a sob story, or a tirade against Apple. Okay, maybe a little bit of a gripe, but I’d like it to be more a focus on the importance of considering edge cases in development.

The customer support reps are incredibly constrained. They knew without a doubt that I could receive calls at the phone number in question. But they weren’t empowered to do anything about it. They escalated the issue, and it seems no-one was about to do anything, apart from offering their condolences that I won’t be able to log into my account.

If there is one take-away from this, I suppose it’s to enable your customer support reps to actually do their jobs. I know Apple has gotten burned in the past on hackers gaming the system, but it’s the importance of being judicious when dealing with requests, not barring the doors against any.

As a semi-related note, I’m heading up the group working on bringing Two-Factor support to WordPress core.  Two-Factor is something that I believe in deeply, I just also believe in the importance of carefully building out the systems that serve as back ends to such methods of authentication.

Update: I’m learning that it’s possible to get some short codes unblocked for a single account specifically … maybe.  Apple authentication texts seem to come from a number `50472` and I’ll be reaching out to Project Fi support tomorrow to see if I can get them to manually unblock that number for my account.

Perfect Faro Shuffles

Faro Shuffling is a technique where two packets of cards are pressed together and stitch themselves together, one to one. It takes a goodly amount of practice to actually pull it off reliably, but if you can, it’s a tremendously fun skill to have.

There are two primary kinds of faros performed on a 52-card deck, that being an ‘In’ and an ‘Out’ faro.  An ‘Out’ faro is one where the top and bottom cards of the deck are preserved on the outside of the deck, an ‘In’ is where they are moved to the interior of the deck.

If the user can perform perfect cuts and faro shuffles, it will take 26 ‘In’ shuffles to completely reverse the deck of 52 cards, and another 26 shuffles to return it to original order. However, by performing ‘Out’ shuffles, the full deck will be returned to the original sequence in only eight shuffles.

I’m working on mastering this, because it’s dang fun and appeals to my brain.  And, as a predictable way of reordering decks and can be rolled into some fun illusions.

For reference, standard new deck order is A♠️-K♠️,A♦️-K♦️,K♣️-A♣️,K♥️-A♥️.

While performing eight perfect cuts and ‘Out’ faros, if you start with standard new deck order, these are the eight cut cards:

  1. K♣️
  2. A♦️
  3. 7♣️
  4. 4♦️
  5. 9♠️
  6. 5♠️
  7. 3♠️
  8. 2♠️

Or, if you prefer Emoji,

🃞🃁🃗🃄🂩🂥🂣🂢

DIY Halloween Costume Smoke

I’m currently experimenting with possibilities for making a combo halloween costume that I could wear with my daughter this year, and I’d always wanted to be able to add a flair of the dramatic to costumes, and smoke is one of the best ways to do it.  Especially when it’s just a touch here or there.

I want it to be portable, and affordable.  Both of these are kinda requirements, honestly, for a once-per-year halloween costume.

In doing some research online, I saw an offhand remark from someone about e-cigarettes, vaporizers, whatever you like to call them, and the more I thought about it, the cleverer it seemed.  The recent pivot in the nicotine industry had driven down the cost of e cigarettes to the point where I could buy a “V2EX Automatic EX Starter Kit for E-Liquid” for about $12 at my local gas station.

Keep in mind, that this is just the e cigarette, not the ‘e liquid’ or the nicotine-laden stuff that makes it go.  By my understanding, that’s the far pricier bit.

So, e cigarette (rechargeable miniature smoke machine) in hand, I’d need at several more things: the fuel that makes it go (as I have no desire for nicotine or flavoring, I decided to forego the ‘e-liquid’), some sort of pump to operate the ‘draw’ that activates the e cigarette, and some way of getting the smoke from the e cigarette to where I want it.

The primary ingredient in ‘e liquid’ is a fun little compound called Propylene Glycol, and indeed you can buy it without the nicotine or flavorings much cheaper — if you have a Compounding Pharmacy anywhere near you, they normally sell it for probably about $10/pint — far more than you would conceivably need for a little smoke machine, but the point is that it’s cheap.  It’s also available on Amazon Prime.  You don’t need to mix it with anything, you can just pour it directly into the refill area of the e cigarette.  Granted, you may want to get an eyedropper or syringe with a blunt needle to do it with, so you don’t make a mess.

Now, we need a delivery method.

I had initially been envisioning some sort of one way dinky little plastic air pump with some hose on it that I could hide either under an armpit or behind a pushable button somewhere on the costume, but while trawling Amazon, found a great option — a 6′ tube with a siphon pump.  Going by its reviews, it’s made just as cheaply as the price indicates, but for our purposes — a one night costume — the price ($7) is right, and free shipping on Prime.

It is missing one-way valves, and I’ve got a set of those coming — again, Amazon Prime — but I don’t have them in hand quite yet.

In all, it’s come out to just about $30, $35 with the one way valves, and it feels totally worth it to add an incredible effect to a costume.

So, all things considered, I’m expecting to have a pretty fun instant smoke addition to a halloween costume this year.  And with the leftover propylene glycol?  Maybe I’ll just practice making smoke rings.  🙂

One friendly warning, though — you do not want polyethylene glycol.  That’s a laxative.  💩

Safari is the new IE

Read the Tea Leaves

Last weekend I attended EdgeConf, a conference populated by many of the leading lights in the web industry. It featured panel talks and breakout sessions with a focus on technologies that are just now starting to emerge in browsers, so there was a lot of lively discussion around Service Worker, Web Components, Shadow DOM, Web Manifests, and more.

EdgeConf’s hundred-odd attendees were truly the heavy hitters of the web community. The average Twitter follower count in any given room was probably in the thousands, and all the major browser vendors were represented ? Google, Mozilla, Microsoft, Opera. So we had lots of fun peppering them with questions about when they might release such-and-such API.

There was one company not in attendance, though, and they served as the proverbial elephant in the room that no one wanted to discuss. I heard them referred to cagily as “a company in California”…

View original post 1,420 more words

Understanding Security Holes

Just finished my talk on Secure Code at WordCamp Philly 2015!  Thanks to everyone who came, here are my slides: