Cornerstone wont load when /wp-admin/ is behind transparent proxy

[daltonrick]

I currently have my /wp-admin/ behind an Nginx reverse proxy. everything seems to work except cornerstone. Seems to be related to Ajax, I get the errors below. Caches have all been cleared.

Proxy Server:

server {
listen 443 ssl http2;
server_name www.subdomain.site.com subdomain.site.com;


ssl_certificate /path/to/bundle-cat;
ssl_certificate_key /path/to/key;

# Cache Purge trigger
location ~ ^/purge(/.*) {
    fastcgi_cache_purge WORDPRESS "$scheme$request_method$purge_override_host$1"
}

##### Restrict attack surface
if ($request_method !~ ^(GET|POST|HEAD)$ ) { return 444; }

location = / { return 301 https://subdomain.site.com/wp-login.php; }

location / {
    proxy_pass https://site.com/;

    proxy_set_header Accept-Encoding "";
    sub_filter 'https://site.com/' 'https://$host/';
    sub_filter '%3A%2F%site.com' '%3A%2F%2F$host';
    sub_filter_once off;

Wordpress Server

root /var/www/site-folder;
index index.php;

ssl_certificate /path/to/bundle-cat;
ssl_certificate_key /path/to/key;

error_page 404 = /wp-content/themes/x/404;
error_page 403 =404 /wp-content/themes/x/404;


server {
    listen 80 default;
    server_name _;

    return 301 https://$host$request_uri;
}


server {
    listen 443 ssl http2;
    server_name www.site.com site.com $server_addr;


	##### Set showstopper locations
	# Block access to internal files
    location ~ ^/(\.|readme.html|licence.txt|wp-config.php|xmlrpc.php) {
        log_not_found off;
        access_log off;
        return 444;
    }

	# Cache Purge trigger
    location ~ ^/purge(/.*) {
        fastcgi_cache_purge WORDPRESS "$scheme$request_method$purge_override_host$1";
    }

	##### Restrict attack surface
	if ($request_method !~ ^(GET|POST|HEAD)$ ) { return 444; }


    ##### Anyone can access, don't waste the diskspace
	location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { access_log off; log_not_found off; expires 7d; }
    location = /robots.txt { allow all; log_not_found off; access_log off; }


	##### Set sharable fastcgi vars
	include snippets/fastcgi-php.conf;

	##### Setup caching
	set $no_cache 0;
	if ($request_method = POST) {set $no_cache 1;}
	if ($http_cookie ~ (comment_author_.*|wordpress_logged_in.*|wp-postpass_.*)) { set $no_cache 1; }


	# Bypass cache if flag is set
	fastcgi_no_cache $no_cache;
	fastcgi_cache_bypass $no_cache;
	fastcgi_cache WORDPRESS;
	fastcgi_cache_key "$scheme$request_method$host$request_uri";

	# Cache times
	fastcgi_cache_valid 404 60m;
	fastcgi_cache_valid 200 60m;
	fastcgi_max_temp_file_size 4m;
	fastcgi_cache_use_stale error timeout invalid_header http_500;

	# Ignore old cache methods
	fastcgi_hide_header Pragma;


	##### catch-all
    location / {
        try_files $uri $uri/ /index.php;
    }


	##### PHP
    location ~ \.php$ {

		location ~ ^/(wp-login.php|wp-admin|x)$ {
			allow 10.128.0.2;
			deny all;

			set $no_cache 1;
			fastcgi_pass php_backend;
		}

        fastcgi_pass php_backend;

Additional global config:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options SAMEORIGIN;
add_header Access-Control-Allow-Origin https://subdomain.site.com;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

Wondering if there is a cookie or header not being passed. Everything works fine when I log in directly to the wordpress server, only breaks when going through the proxy.

[christian]

Hey Dalton,

Thanks for writing in.

The error you posted undoubtedly is related to AJAX and AJAX issues are mostly due to a problem with the WordPress and or server setup. Regretfully, we are not server experts; therefore, we generally are not capable of guiding users through fixing server setups.

Before I point to the possible causes based on the error, I’d first like to let you know that Cornerstone follows WordPress standards and therefore works in many web hosts. What I’m trying to say is, those web hosts are most probably using standard server setup which works with WordPress as a whole and not just parts of it like succeeding in login.

Here are a few possible causes and solutions due to the error message:

1. Closing connection for GET and POST request maybe due to this line if ($request_method !~ ^(GET|POST|HEAD)$ ) { return 444; }
2. Resetting the WP Salt Keys might help.

I’d like to say again that we are not server experts. If those does not help, I’d recommend you move to a standard or a managed WordPress web host.

Thanks.

[daltonrick]

Thanks for your reply, the suggestions didn’t help, which I suspected they wouldn’t since everything worked fine on site.com, but had issues on the proxied admin.site.com for admin pages.

My solution, in case anyone else is attempting to restrict admin pages to a single, specific server (assuming you’ve done everything else needed for a managed instance cluster behind a load balancer with a separate, dedicated admin server) is define internal cookie that I pass to WordPress using fastcgi_param , which is only set on the admin server, and if its set, I do the following in my wp-config.php:

if ((isset($_SERVER['<KEY>'])) && ($_SERVER['<KEY>'] == "<VALUE>")) {
    $my_current_home_url =  'https://subdomain.yoursite.com/';
} else {
    $my_current_home_url = 'https://yoursite.com/';
}

define( 'WP_HOME', $my_current_home_url );
define( 'WP_SITEURL', $my_current_home_url );

[friech]

Thank you for sharing that solution.

Cheers!