为了通过 SSL 轻松启用（和强制执行）WordPress 管理，您可以在站点的wp-config.php文件中定义两个常量。在插件文件中定义这些常量是不够的；它们必须在您的wp-config.php文件中定义。您还必须已经在服务器上配置 SSL 并为安全服务器配置（虚拟）主机，然后您的站点才能在这些常量设置为 true 的情况下正常工作。
注意： FORCE_SSL_LOGIN 在4.0 版中已弃用。请使用 FORCE_SSL_ADMIN。
强制 SSL 登录和SSL 管理员访问 #
可以在 wp-config.php 文件中将常量 FORCE_SSL_ADMIN 设置为 true，以强制所有登录和所有管理会话都通过 SSL 发生。
例子 #
定义（'FORCE_SSL_ADMIN'，真）；
使用反向代理 #
如果 WordPress 托管在提供 SSL 的反向代理之后，但自身托管时没有 SSL，则这些选项最初会将任何请求发送到无限重定向循环中。为避免这种情况，您可以配置 WordPress 以识别 HTTP_X_FORWARDED_PROTO 标头（假设您已正确配置反向代理以设置该标头）。
例子 #
定义（'FORCE_SSL_ADMIN'，真）； // 在某些设置中 HTTP_X_FORWARDED_PROTO 可能包含 // 一个逗号分隔的列表，例如 http,https // 所以检查 https 是否存在 if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='开启';
更多信息 #
如果您使用的是旧版本的 WordPress（理想情况下不应该这样做！），或者您的 SSL 设置有些不同（即您的 SSL 证书用于不同的域），本文的其余部分将作为信息。
有时，您希望整个 wp-admin 使用 https 协议在安全连接上运行。从概念上讲，该过程的工作方式如下：
- 设置两个具有相同 url（博客 url）的虚拟主机，一个安全，另一个不安全。
- 在安全的虚拟主机上，设置一个重写规则，将所有非 wp-admin 流量传送到不安全的站点。
- 在不安全的虚拟主机上，设置一个重写规则，将所有到 wp-admin 的流量传送到安全主机。
- 放入一个过滤器（通过插件）过滤 wp-admin 中的链接，以便一旦激活，管理链接将被重写以使用 https 并编辑 cookie 以仅在加密连接上工作。
以下指南适用于运行 mod_rewrite 的 WordPress 1.5 和 Apache，使用 httpd.conf 中的重写规则（与 .htaccess 文件相反），但可以轻松修改以适应其他托管场景。
虚拟主机 #
除了非安全站点之外，您还需要为安全服务器配置的（虚拟）主机。在此示例中，安全虚拟主机使用与DocumentRoot不安全主机相同的内容。假设您可以使用具有不同名称的主机，例如 wpadmin.mysite.com 并将文档根链接到 wpadmin 目录。
请让您的 ISP 为您设置一个安全的虚拟主机，或者如果您有自己的管理访问权限。请注意，您不能使用基于名称的虚拟主机来识别不同的 SSL 服务器。
重写不安全主机的规则 #
在您的不安全主机的 httpd.conf 中的 .htaccess 或虚拟主机节中，添加此重写规则以在您浏览到 http://mysite.com/wp-admin/ 或 http://mysite 时自动转到安全主机.com/wp-login.php
这应该在主要的 wordpress 重写块之上。
RewriteCond %{THE_REQUEST} ^[AZ]{3,9}\ /(.*)\ HTTP/ [NC]
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]
如果您使用永久链接重写规则，此行必须在RewriteRule ^.*$ - [S=40].
这个块中的一个重要想法是使用 THE_REQUEST，它确保只重写实际的 http 请求，而不是本地直接文件请求，如 include 或 fopen。
重写安全主机规则（可选） #
这些重写规则是可选的。他们禁止通过安全连接访问公共站点。如果您希望使用下面的插件保持登录到您网站的公共部分，则不得添加这些规则，因为该插件会通过未加密的连接禁用 cookie。
安全虚拟主机应在 .htaccess 文件或虚拟主机声明中具有两个重写规则（有关重写的更多信息，请参阅使用永久链接）：
重写规则！^/wp-admin/(.*) - [C] RewriteRule ^ / (. *) http://www.mysite.com/$1 [QSA, L]
第一条规则从下一条规则中排除 wp-admin 目录，该规则将安全站点的流量转移到不安全站点，以使您的受众保持良好和无缝。
设置 WordPress URI #
为了使某些插件正常工作，以及出于其他原因，您可能希望通过设置 https://mysite.com 在选项中设置 WordPress URI 以反映 https 协议。您的博客地址不应更改。
示例配置节 #
注意：以下配置与 WordPress 2.8+ 不是 100% 兼容，WordPress 2.8 使用 wp-includes 文件夹中的一些文件。第一组 Rewrite 规则引入的重定向可能会导致某些用户出现安全警告。有关更多信息，请参阅https://core.trac.wordpress.org/ticket/10079。
<虚拟主机 nnn.nnn.nnn.nnn：443>
服务器名称 www.mysite.com
SSL引擎开启
SSLCertificateFile /etc/apache2/ssl/thissite.crt
SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
SetEnvIf 用户代理 ".*MSIE.*" nokeepalive ssl-unclean-shutdown
DocumentRoot /var/www/mysite
<IfModule mod_rewrite.c>
重写引擎开启
RewriteRule !^/wp-(admin|includes)/(.*) - [C]
RewriteRule ^ / (. *) http://www.mysite.com/$1 [QSA, L]
</IfModule>
...
</虚拟主机>
# 不安全的网站
<虚拟主机 *>
服务器名称 www.mysite.com
DocumentRoot /var/www/ii/mysite
<目录 /var/www/ii/mysite >
<IfModule mod_rewrite.c>
重写引擎开启
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
重写规则 ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C]
重写规则 ^.*$ - [S=40]
RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
...
</IfModule>
</目录>
...
</虚拟主机>
重写登录和注册 #
使用 SSL 进行用户登录和注册可能是一个好主意。考虑以下替代 RewriteRules。
不安全 #
RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]
安全的 #
RewriteRule !^/wp-(admin|login|register)(.*) - [C]
重写在端口 443 或端口 80 上运行的站点 #
# 开始 WordPress
<IfModule mod_rewrite.c>
重写引擎开启
RewriteBase /
# 对于在端口 443 上运行的站点或其他 (http over ssl)
重写条件 %{SERVER_PORT} !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
重写规则 ^(.*)$ http://%{SERVER_NAME}/$1 [L]
# 对于在端口 80 (http) 上运行的站点
重写条件 %{SERVER_PORT} ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]
重写条件 %{SERVER_PORT} ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
重写规则。/index.php [L]
</IfModule>
概括 #
此方法不能修复 WordPress 中的一些固有安全风险，也不能保护您免受中间人攻击或其他可能削弱安全连接的风险。
但是，这应该会使恶意人员更难窃取您的 cookie 和/或身份验证标头并使用它们来冒充您并获得对 wp-admin 的访问权限。它还混淆了嗅探您的内容的能力，这对于可能具有需要严格保护的文档草稿的合法博客来说可能很重要。
确认 #
在作者的服务器上，日志表明 GET 和 POST 请求都是通过 SSL 进行的，并且到不安全主机上的 wp-admin 的所有流量都被传送到安全主机。
示例 POST 日志行：
[Thu Apr 28 09:34:33 2005] [info] 收到子 6 的后续（第 5 号）HTTPS 请求（服务器 foo.com:443） xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] “POST /wp-admin/post.php HTTP/1.1”302 - “https://foo.com/wp -admin/post.php?acti on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"
更多的测试，最好是使用数据包嗅探器和一些核心网络分析工具，将有助于确认。
限制 #
作者假设（但尚未检查）如果用户存储了 cookie/告诉他们的浏览器记住密码（不是基于表单字段，而是使用某些外部身份验证机制）并点击 http://www.mysite.com/ wp-admin/，这些数据包以明文形式发送，cookie/auth 标头可能被截获。因此，为确保最大安全性，用户应明确使用 https 主机或始终在新会话开始时登录。
