Support » Plugin: WP Super Cache » Serving pages from behind a proxy

  • At the top of the htaccess it says, “If you serve pages from behind a proxy you may want to change ‘RewriteCond %{HTTPS} on’ to something more sensible”

    I am in the process of setting up/configuring a WAF (Web Application Firewall). I assume this is the equivalent to serving pages from behind a proxy. I would like the WAF to serve https. Can you provide an example of “something more sensible” to change “RewriteCond %{HTTPS} on”?

    Thanks!

Viewing 8 replies - 1 through 8 (of 8 total)
  • Saša

    (@stodorovic)

    It depends on kind of WAF. If it’s apache module (as mod_security for example) then you don’t need to change anything.

    If it’s reverse proxy then you should replace RewriteCond %{HTTPS} on to RewriteCond %{HTTP:X-Forwarded-Proto} https or RewriteCond %{HTTP:X-Forwarded-Port} 443 but it depends on configuration. If VirtualHost is on custom port then you should also set HTTPS in wp-config.php. More details – https://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy

    Hi @stodorovic

    Here is the situation:

    The WAF provides free SSL delivery and doesn’t require my server to send via SSL. I understand that isn’t completely secure but my websites don’t have carts nor do they collect any sensitive data.

    I tried setting it up using the CDN feature of Super Cache but this still left a number of things as mixed content. I figured if I could serve the https version of the cache to their server that it would eliminate the mixed content issue.

    If I replace RewriteCond %{HTTPS} on with the WAF IP addresses or domain like this:

    RewriteCond %{REMOTE_HOST} ^(.*)\.examplecdn\.com$ [NC,OR]
    RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.444$ [NC,OR]
    RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.555$ [NC]

    Will my sites generate the https cache and serve it to the WAF/CDN?

    Saša

    (@stodorovic)

    They are server rules (for serving files), but WPSC should create https files and it isn’t possible without changes in wp-config.php because there isn’t place where you can add custom code before loading advanced-cache.php.

    So, you need to add similar “rules” in wp-config.php. Something like this:

    // in known, safe manner
    $trusted_proxies = array( '111.222.233.244', '111.222.233.245' );
    
    if ( ! empty( $_SERVER['REMOTE_ADDR'] ) && in_array( $_SERVER['REMOTE_ADDR'], $trusted_proxies ) ) {
        if ( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
            $ip_addr = explode(',',$_SERVER['HTTP_X_FORWARDED_FOR']);
            $_SERVER['REMOTE_ADDR'] = reset( $ip_addr ); 
    	unset( $ip_addr );
        }
        if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
            $_SERVER['HTTPS']='on';
        }
    }
    unset( $trusted_proxies );
    

    You should add it before comment: /* That’s all, stop editing! Happy blogging. */.

    I didn’t test this code, but it’s concept. Related to rewrite rules, it’s possible to use mod_setenvif module to set environment variable which could be used later (to avoid repeating same rules which isn’t perfect for performance).

    There is an issue on github – https://github.com/Automattic/wp-super-cache/issues/634 related to optimization of rewrite rules. Probably you could use something like this.

    Hi @stodorovic

    I have an unrelated but related question to my situation.

    I have a significant number of blogs on my network and all of them are configured for a CDN. As I am moving to SSL I need to update the CDN on all sites to the SSL version.

    Is there a quick and easy way to update all sites settings to the same CDN? Ideally, with the ability to later update them individually.

    Thanks,
    Pat

    Saša

    (@stodorovic)

    It’s possible only with custom PHP script. You need to upload it into root directory (where is index.php,wp-load.php) and execute it in browser (https://example.com/cdn-update.php).

    Script:

    <?php
    
    // Load the WordPress library.
    require_once( dirname(__FILE__) . '/wp-load.php' );
    
    foreach( get_sites( array( 'public' => 1 ) ) as $site ) {
            update_blog_option( $site->blog_id, 'ossdl_off_cdn_url', 'https://cdn.example.com/' );
    }
    

    I hope that you have basic PHP knowledge and you can even get option, replace URL and update it.

    Hi @stodorovic

    I do have a solid foundation in php. I’ve completed a few courses and done quite of bit of my own coding and even contributed to a few plugins – including WP Super Cache several years ago to help get it working with WPTouch Pro. However, when you aren’t coding on a regular basis you tend to lose a few steps.

    I tried the code you provided and the script timed out but nothing was changed.

    I was thinking that it might be easier to do it as a mu plugin. Any thoughts on what that might look like? I will give it a try and let you know how I get on with it.

    Thanks,
    Pat

    Saša

    (@stodorovic)

    It’s possible that some plugin was stuck in bootstrap process. You can add following constants before wp-load.php:

    define( 'DOING_AJAX', true );
    define( 'WP_USE_THEMES', false );
    define( 'SHORTINIT', true );
    

    It stops bootstrap process after multisite init and you can’t use entire WP API (and WPSC isn’t fully loaded), but get_sites and update_blog_option should work.

    Also, if you have shell access then you can run it as shell command. Something like this:

    cd public_html
    php cdn-update.php
    

    In this case you should set virtual $_SERVER global (before wp-load.php). Also, it’s possible that you need to run php-cli instead of php. Example:

    $_SERVER = array(
      "HTTP_HOST"      => "example.com",
      "SERVER_NAME"    => "example.com",
      "SERVER_PORT"    => 443,
      "REQUEST_URI"    => "/",
      "REQUEST_METHOD" => "POST",
    );
    

    Also, it’s possible to move these scripts outside public_html to protect them. I’m running various cron jobs via php-cli (custom preload, backup,…).

    After adding the constants I got a 500 Server Error. I removed them one at a time. It was the shortinit that was causing the error.

    I think it worked up to site 900 but for some reason none after that. Fortunately I only have upto 932 so I was able to manually complete the rest.

    Thanks,
    Pat

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Serving pages from behind a proxy’ is closed to new replies.