1. Do the rewrite rules now work properly inside the Apache config? The rewrite rules posted in this article assume WordPress is in the site root, which probably will work. But using WP in a sub-directory of the site will not work properly, as the RewriteBase directive does not function inside httpd.conf (or included .conf files).
2. Isn't the better solution to get WP to support relative URIs for /wp-admin/, so we can transparently use https if we want (note: will this introduce cookie problems?)? If someone's using SSL, chances are they have complete control of the host (or at least a more expensive hosting account?), so making them jump through these hoops seems ... ineffecient. It also introduces greater risk of breaking: if the rewrite rules get overwritten (intentionally or accidentally), the secure connection gets lost.

Here's another option:

<?php
/*
Plugin Name: https
Plugin URI: http://www.skippy.net/
Description: makes all admin links use HTTPS
Version: 1.0
Author: Scott Merrill
Author URI: http://www.skippy.net/

copyright 2005 Scott Merrill (skippy@skippy.net)
This plugin is licensed under the terms of the GNU Public License, version 2.
*/

if (is_admin()) {
     add_action('core_files_loaded', 'https');
}

function https() {
global $cache_settings;

$site = strtolower(get_settings('siteurl'));
$newsite = str_replace('http://', 'https://', $site);
$cache_settings->siteurl = $newsite;
$cache_settings->home = $newsite;
}

?>

Note: this is currently untested.

Isn't the better solution to get WP to support relative URIs for /wp-admin/, so we can transparently use https if we want (note: will this introduce cookie problems?)?

I thought about that, but didn't get a chance to test it. Your plugin is a lot cleaner and better organized than mine. It's certainly a better method for filtering those urls. I'll test it out.

If you view the cookies that WP sets, you'll see that they are set to send for "any type of connection" so I don't think that your relative URI trick is going to introduce any new issues, and I don't see there being any issues with accidentally transmitting the cookies over plain http.

But using WP in a sub-directory of the site will not work properly, as the RewriteBase directive does not function inside httpd.conf (or included .conf files).

These are example rewrite rules for a special case. However, the RewriteBase directive will work fine inside httpd.conf as long as is it contained in a <Directory>...</Directory> block. All an .htaccess file does is create a Directory block with an implied location. We could note that in the article.

The rewrite rules are primarily there to enforce the use of https -- strictly speaking, they aren't necessary if your users know to access the administrative interface via https. They just make the configuration a little more seamless end-to-end. My goal here was to create a system that closely matches regular WP behavior and elucidates a concept that can be extended for other configuration needs.

--Eads 17:58, 28 Apr 2005 (UTC)

Actually, my plugin is likely to introduce as many problems as it solves. First, the "View Site" link at the top of the admin area will load the main blog via https instead of http. Second, the "General" options page will display https links for the blog URI and home URI, possibly overriding the old values in the database. There might be other unintended consequences, as well.

skippy 18:37, 28 Apr 2005 (UTC)

I've just found this wiki entry after writing a short howto about how I use SSL for Admin access: Securing WordPress Admin Access With SSL I use Apache's mod_proxy and mod_proxy_html to proxy SSL request to the normal HTTP server and to rewrite URLs.

Juergen 14:42, 18 May 2005 (UTC)

The following tested and confirmed plugin should allow passwordless authentication based on client-side SSL certs:

<?php
/*
Plugin Name: Secure Login
Plugin URI: http://skippy.net/blog/
Description: Supports client-side SSL certificate for secure, passwordless logins
Author: Scott Merrill
Version: 1.0
Author URI: http://skippy.net/

copyright (c) 2005 Scott Merrill
released under the terms of the GNU GPL

with thanks to Owen Winkler for help

You'll need the following bits added to your HTTPS vhost
   <Directory /path/to/wordpress>
   SSLVerifyClient require
   SSLVerifyDepth 1
   SSLOptions +StdEnvVars
   </Directory>
If you're not acting as your own CA, you'll likely need to twiddle the SSLVerify
Depth:
   http://www.modssl.org/docs/2.8/ssl_reference.html#ToC18
and possible need to adjust the SSLCACertificateFile setting...

If you're using HTTPS on a non-standard port, change the '443' below to whatever
 port you're using.
*/

add_action('wp_authenticate', 'secure_login');

function secure_login() {
global $wpdb;
// if we're not using https, bail out
if ('443' != $_SERVER['SERVER_PORT']) {
        return;
}

$redirect_to = 'wp-admin/';
if($userdata = $wpdb->get_row("SELECT * FROM {$wpdb->users} WHERE user_email = '
{$_SERVER[SSL_CLIENT_S_DN_Email]}'"))
{
        $username = $userdata->user_login;
        $password = $userdata->user_pass;
        wp_setcookie($username, md5($password), true);
        do_action('wp_login', $user_login);
        wp_redirect($redirect_to);
}
}

?>

I realize the utility of this is limited, but for folks with laptops and SSL-aware servers under their control, this may be useful. Basically, you can safely log in to your WP admin area without a password, by use of a client SSL certificate. This only works if you visit https://example.com/wp-login.php, which will then set your cookie appropriately and send you back to /wp-admin/ via regular http instead of https.

the htaccess rules need alot of work

The example rewrite rules on this are bad, no time to fix right now.. AskApache 07:41, 30 October 2010 (UTC)