Securing WordPress Admin Via SSL Using a Separate Admin Subdomain
Different WordPress and Site URLS
Our wordpress site has an SSL secured admin setup to protect our login credentials. Since we do not have an SSL certificate for our main blog domain, but rather for secure.seriouslyproductions.com , the setup for WordPress to function properly was not standard and required some extra work.
mod_rewrite and Admin Pages
To accommodate this setup and ensure that the login page and all admin content was secured via SSL, I set the wordpress Address (in General Settings) to https://secure.seriouslyproductions.com. The next step was to add a mod_rewrite rule to my .htaccess file to divert all traffic to https://secure.seriouslyproductions.com when attempting to access any admin page or the wp-login.php page.
PROBLEM: Unable to Preview Changes
At this point most things were working. The login and admin pages were secure. The only caveat was that I could not preview changes to any WordPress post or theme settings. In addition, a logged in user would never see the WordPress admin bar at the top of the screen if viewing the blog URL. By default, WordPress sends any preview request back over to the site URL (which in my case is set to http://www.seriouslyproductions.com/). However, to preview a change a user must be logged in and have permissions to view the change. This told me that the authentication cookie wasn’t available across the two domains (secure.seriouslyproductions.com and www.seriouslyproductions.com).
I wanted the preview functionality so I have been on a crusade to determine a way to enable this functionality with my cross subdomain setup. In this earlier blog post I outlined a quick “fix” in which I used mod_rewrite rules that diverted preview post content over to my secured subdomain, https://secure.seriouslyproductions.com. This solution worked for previewing posts and page updates, but failed miserably for previewing my custom theme updates. In addition, this solution gave me SSL warnings because WordPress was serving insecure content over the SSL channel (images and other content) when previewing changes. Clearly this was only a temporary solution, but it worked well enough for the time being.
SOLUTION: Modifying the Cookie Domain
Over the past few weeks, and as time permits, I’ve been doing research and I believe I’ve found the solution to my problem. To start, I removed the “hack” fix that I put in place which diverts preview traffic over to secure.seriouslyproductions.com from the .htaccess file.
Now for some explanation… By default, WordPress authentication cookies are only recognized for the domain entered into the WordPress Address (in my case secure.seriouslyproductions.com). Any visit to www.seriouslyproductions.com will not acknowledge that a user is logged in as it cannot find a “logged in” cookie for the www subdomain. This results in any request to preview content to fail.
The best solution I’ve found is to alter the cookie domain of the WordPress logged in cookie (NOT the auth cookie which is a security risk) to the value of my root domain without a subdomain, i.e “seriouslyproductions.com”. This makes the cookie available across all subdomains of seriouslyproductions.com and now all is well in the world. The code where all authentication cookies are set can be found in the wp-includes/pluggable.php file and is easy to modify.
Once I updated the wordpress logged in cookie’s domain, all my previews work properly and the WordPress install is working like a champ. I can see all preview content, both posts and theme updates, and I don’t receive any SSL warnings when previewing content.
To those who are having similar problems, I’ve glossed over a lot of important details in this post, but if you need further info then don’t hesitate to ask me for it and I’ll flesh out this article some more.