Converting a WordPress Plugin Store to HTTPS

A few weeks ago, I was experimenting with https:// on the site for my plugin, ACF Widgets. I added the SSL cert for my domain using Let's Encrypt and the requests were being handled fine, but I was only enforcing SSL on the checkout page. If you hit the ACF Widgets site with https:// initially, everything worked fine, but my login rules were causing some issues with people logging in to the support forums.

After 4 or 5 people contacted me through other channels telling me they couldn't log in to get support, I decided to look into it a little more closely. As it turns out, the login pages were trying to work over SSL while people were trying to login with insecure http:// POST requests. Whoops!

To fix this problem, I needed to convert the whole site to use https:// all of the time. This too worked out fine and wasn't an issue. 3 lines in .htaccess that you can find on a million different blogs. Super easy stuff. What made things more difficult, was upgrading the URL for my plugin to check and receive automatic updates.

The problem with copying .htaccess rules

I think this goes back to a fundamental flaw with humans, in that we want results and we want them immediately. In 99% of the tutorials I found, most of them advocated for an .htaccess rule that looks something like this:

https://gist.github.com/Daronspence/0ee938c180b05bccae72aa4775e70387

Generally, this will work, and it's fine. Let's go through it line by line.

  1. Turn the Rewrite Engine on. This tells apache that we're going to do a rewrite so it can load the required modules.

  2. Set a condition. In this case, return true if the server is listening on port 80. (The standard port for HTTP)

  3. Redirect the request to the given URL and pass in the URL query parameters.

Like I said, for most sites this works fine. However, when I pushed the next update to my plugin, I noticed I wasn't getting any update notices. Why wasn't it working?!

Now, in my most recent plugin update, I updated the store URL to my new https:// domain, so after everyone updated, I know whatever weird issue going on would probably go away. I did some tests and sure enough, requesting the update using the https:// store URL triggered an update. So why wasn't it working with the http:// URL? What was happening during the redirect that broke things?

Since I have almost 500 customers, sending an email asking everyone to manually re-install this new version of my plugin was unacceptable. I knew I could do better. I decided to dig-in to the inner workings of APACHE and HTTP a little bit to understand what was going on behind the scenes.

A brief history of redirects in HTTP

So from my understanding of reading numerous blogs, is that the original intent of the HTTP/1.1 spec, was that if no redirect status code was specified (ie. 301, 302, etc) that the client was supposed to treat it as the same method as the original request. So if I send a POST request to /my-api-endpoint/ , the client should honor that POST request and it's data if I do not specify a status code. In APACHE's mod_rewrite this looks like:

RewriteRule ^(.*)$ https://example.com/$1 [R]

Using the [R] flag with no options.

Somewhere along the way (I've seen both IE and Netscape blamed) browsers and HTTP clients in popular languages begin to interpret any missing status code as a 302. In the HTTP spec, a 302 request is for GET requests only. Herein lies the problem with our updates.

EDD Software Licensing Update Process

To understand why updates are failing, I also needed to examine the source code for the update script I was using. At the time of this writing, ACF Widgets is build upon Easy Digital Downloads and the Software Licensing Add-On. It works great! Though in my case, updating the store to https:// was obviously causing issues. Digging in to the code, we find this:

https://gist.github.com/Daronspence/b3bd3b13c86b90348ea409858c9d3c70

And herein lies our problem. EDD SL uses wpremotepost() to send API requests to the URL of our plugin store, which is fine, nothing wrong with that. However, when our POST request to our EDD store encounters a redirect without a specified status code, cURL redirects to a GET request for the homepage with no query parameters. Since that's obviously not what we want, the EDD SL update script fails silently (like it should) so we don't clutter the users dashboard with errors in case our store is down for any reason. In our case though, we want to preserve that POST request and any data we send. So how do we do that?

Enter the Magical Hero Extraordinaire Status Code™, 307

According to HTTP Status Code Spec, a 307 code should behave thusly:

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

Perfect! That's exactly what we want! In short, this will preserve our POST request and any data we send. So now we can use this in conjunction with a normal 301 request to route all of our traffic through our newly secured domain.

https://gist.github.com/Daronspence/ddecc024eda111b38d389368fdbd0cc6

So line by line, let's go through this new .htaccess.

  1. Turn on Rewrite Engine

  2. Check for a request on port 80

  3. Check for the GET request method

  4. Redirect (via a 301 for SEO purposes) and ignore all other rewrite rules ([L] flag).

Now if we don't have a GET request (maybe we have an API that uses PUT, POST, or DELETE) it will get routed through the second rule.

  1. Check for a request on port 80.

  2. Perform a 307 redirect, thus preserving our request method and data. Also, ignore any more rewrite rules ([L] flag).

Now for those of you worried about SEO, don't worry. Google only cares about your visible stuff, AKA GET requests. You shouldn't get a penalty for other request types (because Google won't even know to access them).

As you can see, 307 redirects can be extremely powerful. With the correct caching headers, you can even instruct clients to cache the results while you update your API or tools to use your new secured endpoints, without sacrificing security.

So what next?

Since we now have a our store properly configured to redirect requests from plugins out in the wild, there isn't anything else to do except wait. Customers will update the plugin to the new version which uses the new https:// store endpoint. If you have detailed stats about version usage for your plugin, you could eventually remove the redirect, though I don't see a reason to for the vast majority of plugin stores out there. If anything, it's a good catch all for anything you may add in the future and forget about.

Questions? Comments? Leave 'em down below. I would love to hear from you!

Posted in:

WordPress