SSL for WordPress Admin and the Problem with XMLHttpRequest

Posted on 2 minute read

× This article was imported from this blog's previous content management system (WordPress), and may have errors in formatting and functionality. If you find these errors are a significant barrier to understanding the article, please let me know.
Note! The updates to SSL handling in WordPress version 2.6 handle the problem of SSL-encrypted admin sessions in a much less hackish sort of way. It doesn't make any sense to use this plugin with WordPress version 2.6 when you can simply add define(’FORCE_SSL_ADMIN’, true); to your wp-config.php file.

The WordPress Codex has documentation for running the login, registration, and administration interfaces on an SSL server. There is even a plug-in that will do much of the heavy lifting for you. I have found both of these methods, by themselves, to be rather unsatisfactory, though, in that admin services that rely on AJAX calls back to WordPress break (such as the periodic saving of drafts). What happens is this:

  1. Plugins will use the 'siteurl' and/or 'home' values in the Options → General admin page, and that value is typically set to the "http://" rather than "https://" address of the blog.
  2. The URL that plugins construct to talk back to the WordPress installation will go to an "http" address instead of the SSL-encrypted "https" address.
  3. The admin page, loaded in the browser from the "https" address, attempts to talk back to the WordPress installation on a "http" address and triggers a exception. In Firefox, the error looks like this: Error: [Exception... "'Permission denied to call method XMLHttpRequest.open' when calling method: [nsIDOMEventListener::handleEvent]"...]

The security model in the browser prevents scripts on a page from using XMLHttpRequest ((See http://en.wikipedia.org/wiki/XMLHttpRequest for more information on XMLHttpRequest.)) back to any host on the internet except for the host where the script came from. In this case, the difference between "http://..." and "https://..." is enough to trigger the problem.

So I fixed it with plug-in that uses an undocumented hook in WordPress 2.3. If a plugin requests the value of 'siteurl' or 'home', a filter is called to check if the requested page is on the SSL server. If it is, the filter changes the URL from 'http' to 'https'. In that way, plug-ins will use the proper form of the URL.

< ?php
/*
Plugin Name: Fix Admin SSL
Plugin Script: fix_admin_ssl.php
Plugin URI: http://dltj.org/tag/fix_admin_ssl
Description: Fix the 'siteurl' and 'home' option values to make the protocol 'https' rather than 'http' when the page was requested with SSL.
Version: 1.0
License: GPL
Author: Peter Murray
Author URI: http://dltj.org/about
 
=== RELEASE NOTES ===
2008-02-18 - v1.0 - first version
*/
 
function fix_admin_ssl($url) {
  if ($_SERVER['HTTPS'] == 'on') {
    $url=preg_replace('/^http:\/\//','https://',$url);
  }
  return $url;
}
 
add_action ('option_siteurl', 'fix_admin_ssl', 1);
add_action ('option_home', 'fix_admin_ssl', 1);
 
?>

One downside to this plug-in, though, is that it will appear to change the values of 'siteurl' and 'home' on the Options → General admin page. The values in the database are still the 'http' ones, but since the Options page is an admin page the filter will run when it pre-loads those form fields.

If there is interest, I can package up the above code into a legitimate plugin and submit it to the WordPress plugins list.