This most likely broke in 1.3.21 because we sanitized all GET/POST input with htmlentities(). In 1.3.24 we only sanitize the CloudFlare Plugin specific values. I assume your issue is fixed in 1.3.24. Can you confirm?
@jwineman – I will bring back up the plugins and page rules and report back.
Thanks!
Stu
The particular site is a subdomain which never exhibited problems using Flexible SSL. Even now, when reverting back to 1.3.20 I have a red X in the browser address bar over the https after flushing everything and restarting php5-fpm and nginx
Plugin (SSL Tests) It looks like your server is behind a reverse proxy. The recommended setting for HTTPS detection is HTTP_X_FORWARDED_PROTO.
Your server environment shows this:
Array
(
[HTTPS] =>
[HTTP_CF_IPCOUNTRY] => CA
[HTTP_X_FORWARDED_FOR] => 216.8.156.215
[HTTP_CF_RAY] => 28b522077f863fc5-YUL
[HTTP_X_FORWARDED_PROTO] => https
[HTTP_CF_VISITOR] => {“scheme”:”https”}
[HTTP_CF_CONNECTING_IP] => xxx.8.xxx.215
[HTTP_CF_RESPECT_STRONG_ETAG] => 0
)
I have Flexible SSL “On” in Cloudflare. I have Cloudflare Flexible SSL plugin (by Paul G.) installed. My page rule is *sub.domain/* – always uses https and the CF plugin, email address, api token etc all seem to be fine.
I have to turn it all back off at this point to give my client her site back temporarily until I can figure this out.
Thanks for any assistance you can provide. I’m stumped now that rolling back to 1.3.20 something is seriously stuck.
Hi Stu,
If you look at the variables being persisted in the database for the Flexible SSL plugin are any of them still escaped using htmlentities(). Its possible your data is in a bad state.
Thanks,
John
I’m also on Flexible SSL and never had the problem. The only difference I see in our setup is that I have WordPress HTTPS plugin installed
https://wordpress.org/plugins/wordpress-https/
Install it and set “Yes” to Proxy on its settings page. Hope this helps!
@marhgil what version of the CloudFlare plugin are you using though?
@jwineman i’m using the latest 1.3.24
Thanks for your attentiveness on the support threads here @jwineman – makes sense I will check it out in the db and get that fixed up.
Stu
Btw, I don’t use the Cloudflare Flexible SSL plugin.
I only use the Cloudflare plugin and the WordPress HTTPS. On Cloudflare, I’m on Flexible SSL with Pagerule *mysite.com* to Always Use HTTPS.
Thanks @marhgil
I discontinued using the HTTPS Plugin about a year ago for what I believe is a more elegant solution (the subdomain issue above is an isolated case) working on several hundred installs.
I use these plugins:
CloudFlare
CloudFlare Flexible SSL
Insecure content Fixer
wp-config.php – right before require_once(ABSPATH . ‘wp-settings.php’);
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';
If the site is being converted and not built from scratch I just replace all instances of http://url.url with //url.url in the existing database.
@jwineman – all good now. For whatever reason that one particular site hiccuped all by itself. With all the plugins in their most current version I restored the database from Monday and it’s as good as new.
As far as unescaped htmlentities I don’t have any experience on how to go about finding them, and on the web it’s a very abstract topic. For now I’m happy to have it solved.
Thanks again for pointing me in that direction.
Stu
@stu sorry I should have been more clear. htmlentities() converts characters to their HTML entity equivalent ex “<” -> “<“. What I assume happened is when you upgraded to 1.3.21 our code accidentally ran htmlentites() over variables used by the Flexible SSL plugin and stored in the database in their escaped format, breaking functionality.
Regardless I’m glad your issue is resolved!
Thanks,
John
