This topic created in 4108 days ago, the information mentioned may be changed or developed.
这是一个修复 Wordpress 在使用 Cloudflare Flexible SSL 时，出现无限个重定向循环的问题的插件和原理介绍：
https://www.icontrolwp.com/2014/10/enabling-cloudflares-universal-flexible-ssl-wordpress-without-infinite-redirect-loops/
其中写到：
As with all things that are simple, when combined with WordPress it’s never, ever as easy as you’d like.
You can’t just pop into CloudFlare and turn on Flexible SSL.
Why? Because with Flexible SSL, the web requests that hit your actual WordPress site are actually still “non-SSL”. This means that when WordPress responds with assets/links, it’s still using the non-SSL protocol: “HTTP://” instead of “HTTPS://”.
You need a way to “trick” WordPress into serving the site as-if it’s actually running on HTTPS.
To facilitate this, we’ve created a very simple WordPress plugin to do just that. It examines the traffic and request headers coming to your WordPress site and if it sees it’s coming from CloudFlare, and it’s HTTPS, we turn on SSL for WordPress, tricking it into believing it’s an HTTPS/SSL connection.
当你使用 Flexible SSL 时，(Cloudflare)向你用于搭建 Wordpress 的主机发送的 Web 请求，自然而然不经 SSL 。这意味着 Wordpress 响应请求时发出的元素/链接，都非 SSL 连接。链接将仍使用 HTTP 而不是 HTTPS 协议。
插件的 PHP 代码是这样写的：
if ( isset( $_SERVER['HTTP_CF_VISITOR'] ) && strpos( $_SERVER['HTTP_CF_VISITOR'], 'https' ) !== false ) {
$_SERVER['HTTPS'] = 'on';
}
我的疑问：
经过我的测试，为什么除了 Wordpress 之外的许多程序都没有这个问题呢？按这个原理，Flexible SSL时，其他PHP程序也会响应 non-SSL的元素/链接，用户浏览器访问的依然是 HTTPS 的元素/链接，可是丝毫没有无限死循环的问题。
谁能更清楚的解释一下这方面的原理呢？
https://www.icontrolwp.com/2014/10/enabling-cloudflares-universal-flexible-ssl-wordpress-without-infinite-redirect-loops/
其中写到：
As with all things that are simple, when combined with WordPress it’s never, ever as easy as you’d like.
You can’t just pop into CloudFlare and turn on Flexible SSL.
Why? Because with Flexible SSL, the web requests that hit your actual WordPress site are actually still “non-SSL”. This means that when WordPress responds with assets/links, it’s still using the non-SSL protocol: “HTTP://” instead of “HTTPS://”.
You need a way to “trick” WordPress into serving the site as-if it’s actually running on HTTPS.
To facilitate this, we’ve created a very simple WordPress plugin to do just that. It examines the traffic and request headers coming to your WordPress site and if it sees it’s coming from CloudFlare, and it’s HTTPS, we turn on SSL for WordPress, tricking it into believing it’s an HTTPS/SSL connection.
当你使用 Flexible SSL 时，(Cloudflare)向你用于搭建 Wordpress 的主机发送的 Web 请求，自然而然不经 SSL 。这意味着 Wordpress 响应请求时发出的元素/链接，都非 SSL 连接。链接将仍使用 HTTP 而不是 HTTPS 协议。
插件的 PHP 代码是这样写的：
if ( isset( $_SERVER['HTTP_CF_VISITOR'] ) && strpos( $_SERVER['HTTP_CF_VISITOR'], 'https' ) !== false ) {
$_SERVER['HTTPS'] = 'on';
}
我的疑问：
经过我的测试，为什么除了 Wordpress 之外的许多程序都没有这个问题呢？按这个原理，Flexible SSL时，其他PHP程序也会响应 non-SSL的元素/链接，用户浏览器访问的依然是 HTTPS 的元素/链接，可是丝毫没有无限死循环的问题。
谁能更清楚的解释一下这方面的原理呢？
5 replies • 2015-01-27 07:15:43 +08:00
 |
1
clowwindy Jan 27, 2015  1
因为 wordpress 页面上的地址都是完整 URL。如果是相对路径就没这个问题
|
 |
2
NeoAtlantis Jan 27, 2015 1
Cloudflare的SSL和中间人“攻击”一样。Cloudflare知道传送了什么。
用户用SSL连接到Cloudflare。Cloudflare用或者不用SSL（用了也不一定验证你的证书）来和你的站连接。 根据你上面的英文描述，似乎Wordpress总是没有被经过SSL访问过，所以不断让浏览器转向SSL，然而浏览器虽然转向了SSL的url，但是Cloudflare可能还是在用普通连接访问Wordpress。我是这么理解的。 |
 |
3
ryd994 Jan 27, 2015
自己签一张证书然后用Full不就行了？
|
 |
4
Septembers Jan 27, 2015 1
HSTS
|
 |
5
kiritoalex Jan 27, 2015 via iPhone 1
HSTS+1
|
Select Language