Mon Jul 14 2008 by Ryan
If your host supports SSL, WordPress 2.6 enables you to make use of that support in a secure manner. Enjoy, and help us make SSL support better by reporting any bugs you find.
The auth cookie, on the other hand, is delivered only for the admin area and can be used to make changes to the blog. If you login via https, your auth cookie will be delivered only for SSL sessions. If you login over https and later visit your admin via regular http, you will have to log in again to get a non-SSL auth cookie. By default, you have the option of visiting your admin either via http or https. If you want to force all admin sessions to be over https, add the following to your wp-config.php:
This will prevent non-SSL logins to your blog. This means you will never have an auth cookie delivered in the clear. If you want to force logins to be over SSL to prevent usernames and passwords from being sent in the clear while letting your users have the choice of using http or https when visiting the admin, add this to your wp-config.php:
This does not force all cookies to be delivered over SSL. The user has a choice between the greater security of an https session and the greater speed of an http session. If you want to remove this choice and force secure https sessions, FORCE_SSL_ADMIN is for you.
With these new cookies comes new secret keys for signing them. Recall that WordPress 2.5 introduced SECRET_KEY as a means of adding a little extra security to cookie signing. If you intend to use the SSL support in 2.6, you will probably want to define the secret key for the secure cookie. If you don’t intend to use SSL, you can stick with your existing SECRET_KEY. Here’s an example of what the new secret key definitions look like:
define(’AUTH_KEY’, ‘put your unique phrase here’);
define(’SECURE_AUTH_KEY’, ‘put your unique phrase here’);
define(’LOGGED_IN_KEY’, ‘put your unique phrase here’);
You should change those sample phrases to unique, preferably random phrases. Each key should have a different phrase. Visit http://api.wordpress.org/secret-key/1.1/ to get a set of random keys that you can cut-and-paste into your wp-config.php. Once again, if you don’t intend to use SSL, you can stick with the SECRET_KEY you already have.
This should be mostly transparent to plugins and themes. I say mostly because there are some themes that send POST and AJAX requests to files within the themes directory. The auth cookies are delivered only to the wp-admin and wp-content/plugins directories, so files directly loaded from wp-content/themes will not see the cookies. Themes should send their POST and AJAX requests to the admin-post.php or admin-ajax.php files. I’ve added a short article to the codex on how themes and plugins should handle their POST and AJAX requests.
Plugins might also create links that are not properly prefixed with ‘https’. Any content loaded into a secure page must come via an https link to avoid warnings from the browser about the content being only partially encrypted. WordPress 2.6 introduces five new functions that take care of using the proper protocol when loading CSS, JS, and other files into an SSL-encrypted admin page. They are site_url(), admin_url(), includes_ur(), plugins_url(), and content_url(). Each accepts an optional path relative to the site, admin, include, plugins, and content urls, respectively. For example, to link to wp-content/plugins/foo/foo.php use plugins_url(’foo/foo.php’). Plugins that load CSS and JS via relative links do not need to use these functions. Relative links will automatically use the proper protocol.