WordPress (WooCommerce?) forces https (when it shouldn’t)

2 Views

I’m experiencing a strange issue on a WooCommerce installation my company has taken over. It’s not us who built it and unfortunately it’s pretty crappy built so I’m not so sure what’s actually going on in there.

It suddenly started to “force” https connections, but as far as I know nothing has changed in nether the code nor from the admin. We are running Git on the server and nothing has changed in the working tree, and I searched the uploads folder for suspicious files with no results. It’s very unlikely some kind of malware. The site is not set up with https/ssl so this does of course trigger a timeout.

Read More

I checked the database and both home_url and site_url are set to “http://…”. The WooCommerce option “force ssl” is set to false. Also we are running the plugin “Better WP Security/iThemes Security” which also offers a “force ssl”-option but that one is set to false too.

I tried setting both the constants FORCE_SSL_ADMIN and FORCE_SSL_LOGIN to false in wp-config.php – still no luck. Also I tried using .htaccess rewrite rules but that didn’t help either.

It seems to be connected with a request header; HTTPS: 1 (tested with $ curl -I -H"HTTPS: 1" http://...). When that one is set to 0 this does not happen. However Chrome seems to send it by default, which is not the case for other browsers. I tried clearing cookies/data etc. Problem appears in my colleague’s browser as well (and she has never visited the site before). Hosting company says this is not related to server configuration.

Has anyone experienced this before, or know to what it could be related to?

Update:
Running curl -I -H"HTTPS: 1" http://www.example.com/wp-admin/ pretty much confirms this has something to do with WordPress. The cookies are set by WPML which indicates WordPress is initialized. Check the Location: header: 

HTTP/1.1 302 Moved Temporarily
Server: Apache
X-Powered-By: PHP/5.6.11
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Set-Cookie: _icl_current_admin_language=sv; expires=Wed, 22-Jul-2015 16:06:25 GMT; Max-Age=7200; path=/wp-admin/
Set-Cookie: _icl_current_language=sv; expires=Thu, 23-Jul-2015 14:06:25 GMT; Max-Age=86400; path=/
Set-Cookie: PHPSESSID=xxx; path=/
Location: https://www.example.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.example.com%2Fwp-admin%2F&reauth=1
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
Date: Wed, 22 Jul 2015 14:06:26 GMT
X-Varnish: nnn
Age: 0
Via: 1.1 varnish
Connection: keep-alive
Post Views: 2

Related posts

4 comments

  2. @Zertuk’s solution is correct: upgrading to the latest WooCommerce should fix the issue because of the change that @Zertuk has linked.

    To give more detail: Chrome has implemented the Upgrade Insecure Requests specification from the World Wide Web Consortium (W3C). Section 3.2.1 of that specification is The HTTPS HTTP Request Header Field which states

    3.2.1. The HTTPS HTTP Request Header Field

    The HTTPS HTTP request header field sends a signal to the server
    expressing the client’s preference for an encrypted and authenticated
    response, and that it can successfully handle the
    upgrade-insecure-requests directive in order to make that preference
    as seamless as possible to provide.

    This preference is represented by the following ANBF:

    “HTTPS:” *WSP “1” *WSP

    WooCommerce’s is_ssl() function before version 2.3.13 was incorrectly rewriting all the URLs in the response if the HTTPS: 1 header was set.

    Upgrading to the latest version of WooCommerce (currently 2.3.13) fixes the bug.

  3. I fixed this issue by turning off the Force SSL setting within WooCommerce Settings, and then explicitly setting these 3 WooCommerce pages to use SSL via the checkbox provided as part of this plugin (on the Edit Page screen).

    The pages that needing SSL according to WooCommerce are:
1. Checkout
2. Checkout -> Pay
3. My Account

    and also try,

    <?php 
if (is_ssl()) {
 //action to take for page using SSL
}
?>

    Returns true if the page is using SSL (checks if HTTPS or on Port 443).

  4. Kirby is right.

    I did a quick fix modifying the WordPress core function is_ssl().

    I return false at the beginning of the function because some of my websites do not have SSL.

    It’s not recommended modify the core of WordPress because of the updates, but I can control that.

Comments are closed.