Domain Mapping, Jetpack and HTTPS on original domain admin pages

Hi,

I've run into a problem with the option "Force http/https (Only for original domain)" set to "Yes" and "Administration mapping" left to "domain entered by the user" in combination with Jetpack activated Network wide (don't know if that makes a difference).

This causes some links on the Jetpack admin pages to use the HTTPS protocol even if visited on the mapped domain admin. For example, the buttons "Settings" and "My Jetpack" at the top of the screen, the "Debug" and "Disconnect" links in the footer, or any of the "De/Activate" and "Configure" links on the modules list. Following such a link will cause an infinite loop between HTTPS and HTTP.

Effectively, this cripples control over Jetpack modules and prevents setting up any new connections with WordPress.com or even removing existing ones.

Is there any way to make Domain Mapping (with TLS on the original domain) and Jetpack work together?

  • RavanH

    Hi Kasia, thanks for taking this up :slight_smile:

    I've got W3 Total Cache installed on the network (with only DB and Object Caching enabled) and the whole thing is running on an Nginx server (so no .htaccess) with FastCGI Cache. The FastCGI Cache is set to refrain from caching anything when logged into WordPress so that should not be a problem. But maybe the DB or Object caching from W3TC are interfering.

    For now, I've got the Domain Mapping option "Force http/https (Only for original domain)" switched to "No" again, otherwise site admins cannot even post anything. I went into the DB and changed the root site home and site_url entries in the wp_options table to https://... so now at least the root sites admin pages are always on TLS without Domain Mapping having to force anything.

    But the admin on sub-sites (this is a subdirectory MS installation) without any mapped domain can still be accessed via HTTP. I'd like to be able to force all subdirectory admins to HTTPS too.

    I'll test again with the W3TC caching modules switched off and report back :slight_smile:

  • RavanH

    I'll test again with the W3TC caching modules switched off and report back :slight_smile:

    Switched off all W3TC modules and enabled" Force http/https (Only for original domain)" again but the issue comes back. I can access the admin on a mapped domain on HTTP and the main admin menu (on the left) links are all with the HTTP protocol, which is OK but as soon as I go deeper (for example, Posts > All posts > Edit) I end up on the infinite loop again.

      • RavanH

        can you check if you switch "Administration mapping" to "original domain"?

        Yes, that works better. No infinite loop anymore. Only downsides are:
        1. is that going from the admin (on a subsite) to the front end of that site, I'll not be logged in any more. This in spite of the Cross-domain autolog being set to Yes... This makes the Preview Post button useless and is a bit of a hassle getting back to the back-end (logging in on the mapped domain will redirect me to the admin of the root site, not the subsite!) but it's better then not being able to log in at all...
        2. Jetpack is now connecting to WordPress.com from the original domain which conflict with the domain used on the front end. Some modules (like Publicize and the WordPress.com SSO module) have issues with that.

        Thanks for your help. I'll keep the settings like this for now. I just hope this can be made to work more coherent so please keep me posted if you find out anything more :slight_smile:

  • Vinod Dalvi

    Hi @RavanH,,

    Thank you for your patience here.

    Would you mind if I logged in to your site and did some troubleshooting? This might help get to the bottom of this faster. If this is ok, just grant me temporary admin access to your site by clicking "Grant Access" button in the WPMU DEV Dashboard Settings as described on the following page and reply on this thread after granting it?

    https://premium.wpmudev.org/manuals/wpmu-dev-dashboard-enabling-staff-login/

    Regards,
    Vinod Dalvi

  • RavanH

    Hi Vinod, sure :slight_smile: access is granted on m-etropolis.com. Please note that the Domain Mapping settings are now fairly OK (site admins can post and preview without infinite redirect, back-end is forced to HTTPS on the original domain which is cool) except that this setup causes problems with Jetpack.

    You can see that on a sub-site like outlawpoetry. Browse from Network Admin > Sites to the /outlawpoetry/ Dashboard, then to Jetpack and hit the Debug link at the bottom. Let it load (takes a while) and you'll see the first error IDENTITY_CRISIS which is directly related to a front- and back-end domain mismatch. Do you think there is any way to make Jetpack always connect with the mapped domain? The front-end domain is needed for correct stats and social sharing links...

    If this is not possible, I'd like to be able to force admin pages to the mapped domain (no HTTPS anymore but at least Jetpack does have an IDENTITY_CRISIS then) without the infinite redirect issues described in the original post of this thread.

    Hope you can find out more :slight_smile:

  • Jack Kitterhing

    Hiya @RavanH,

    Whoops! Sorry missed that you was on Nginx. :slight_smile:
    I've looked into this and also had a chat with Sam, the lead developer of Domain Mapping.

    Can you try setting the login mapping to mapped domain, rather than domain entered by the user and then reply back with your server block (if possible). I've just setup a test server on Linode using Nginx with W3 total cache, domain mapping etc, my SSL was self signed, but I didn't encounter any redirect loops.

    I had domain mapping set to force mapped domains and jetpack worked perfectly, let us know if it still doesn't work though and Sam will further investigate. :slight_smile:

    Thanks!

    Kind Regards
    Jack.

  • RavanH

    Hi Jack, I've set the login mapping to "Mapped domain". Nginx server block:

    server {
            listen		80;
            listen		[::]:80;
    	listen		443 ssl;
    	listen		[::]:443 ssl;
    
            server_name	m-etropolis.com *.m-etropolis.com
    			http://www.outlawpoetry.com
    			johnbennett.outlawpoetry.com
    			toddmoore.outlawpoetry.com
    			bashosroad.outlawpoetry.com
    			nbcoop.outlawpoetry.com
    			jackmicheline.outlawpoetry.com
    			northofkafka.outlawpoetry.com
    			onceuponatime.outlawpoetry.com
    			kellrobertson.outlawpoetry.com
    			markweber.free-jazz.net
    			benlindgren.free-jazz.net
    			zerx.free-jazz.net
    			michaelvlatkovich.free-jazz.net
    			americanclave.free-jazz.net
    			vivre-sain.fr http://www.vivre-sain.fr
    			legaragesaintnazaire.com http://www.legaragesaintnazaire.com;
            server_name_in_redirect off;
    
            root /var/www/m-etropolis/htdocs;
            index index.php index.html index.htm;
    
            access_log  /var/log/nginx/m-etropolis.com.access.log;
            error_log  /var/log/nginx/m-etropolis.com.error.log;
    
            ssl_certificate /var/www/m-etropolis/cert/m-etropolis-unified.crt;
            ssl_certificate_key /var/www/m-etropolis/cert/m-etropolis.key;
    
            ##
            # cache stuffs
            ##
    
            set $skip_cache 0;
    
            # POST requests and urls with a query string should always go to PHP
            if ($request_method = POST) {
                    set $skip_cache 1;
            }
            if ($query_string != "") {
                    set $skip_cache 1;
            }
    
            # Don't cache uris containing the following segments
            if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-.*.php|robots.txt|sitemap(-[a-z0-9_-])?.xml)") {
                    set $skip_cache 1;
            }
    
            # Don't use the cache for logged in users or recent commenters
            if ($http_cookie ~* "mp_globalcart_[a-f0-9]+|comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
                    set $skip_cache 1;
            }
    
    	##
    	# rewrites and location specific
    	##
    
            if (!-e $request_filename) {
                    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
                    rewrite ^(/[^/]+)?(/wp-.*) $2 last;
                    rewrite ^/[^/]+(/.*.php)$ $1 last;
            }
    
    	location ~ ^/wp-content/cache/minify/(.+\.(css|js))$ {
                    try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?file=$1;
    	}
    
           location / {
                    try_files $uri $uri/ /index.php?$args;
            }
    
            location ~ \.php$ {
                    	limit_req zone=flood burst=40;
    
                    try_files $uri =404;
    
                    fastcgi_pass   php;
                    fastcgi_index  index.php;
                    include fastcgi_params;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    fastcgi_param SERVER_NAME $http_host;
    
                    fastcgi_next_upstream error timeout invalid_header;
    
                    fastcgi_cache_bypass $skip_cache;
                    fastcgi_no_cache $skip_cache;
    
                    fastcgi_cache WORDPRESS;
                    fastcgi_cache_valid 200 60m;
            }
    
            location ~ /purge(/.*) {
                    fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
            }
    
            location ~ ^/wordpress/(.*)$ {
                    access_log off; log_not_found off; expires max;
                    try_files $uri /$1 /wordpress/index.php?$args;
            }
    
            location ~ ^/downloads/(.*)$ {
                    access_log off; log_not_found off;
                    try_files $uri /files/downloads/$1;
            }
    
            # Security
    	location = /wp-login.php {
                    	#limit request to 1 per second against brute force attacks
                    	limit_req zone=login burst=10 nodelay;
                    	include fastcgi_params;
                    	fastcgi_pass php;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    fastcgi_param SERVER_NAME $http_host;
    	}
            location = /xmlrpc.php {
                    #limit request to 1 per second against brute force attacks
                    limit_req zone=login burst=10 nodelay;
                    include fastcgi_params;
                    fastcgi_pass php;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    fastcgi_param SERVER_NAME $http_host;
            }
            location ~ /\. {
                    deny  all;
                    	access_log off;
                    	log_not_found off;
            }
    
    	# Stuffs
            location ~* ^.+\.(css|js|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
                    access_log off;
                    log_not_found off;
                    expires max;
            }
    
            location = /robots.txt {
                    allow all;
                    log_not_found off;
                    access_log off;
                    try_files $uri /index.php;
            }
    
            location ~* /sitemap(-[a-z0-9_-])?\.xml {
                    allow all;
                    log_not_found off;
                    access_log off;
                    try_files $uri /index.php;
            }
    
    }

    The server uses Nginx FastCGI Cache and memcached is running for Database + Object caching by W3TC.

  • RavanH

    Hmmm, not sure if this is because of the login mapping being set to "mapped domain" or something else but the infinite redirect loop is back. Or maybe it was never realy gone...

    In any case, this happens when on a sub site HTTP front end (example mapped.dom) accessing login via an url like http://www.mapped.dom/wp-admin/ then entering login info I get redirected for a long time, ending with the error "too many redirecct" on an URL like https://www.mapped.dom/wp-login.php?redirect_to=http://original.dom/site/wp-admin/

    Note that suddenly the mapped domain is now on HTTPS while trying to redirect to the original domain on HTTP !! It should be at least the other way around.

    I suppose that is what is causing these loops. One redirect between the original and mapped domain and another between HTTP and HTTPS. Each time crossing over which is caused by that redirect_to query parameter passing either the wrong domain or the wrong protocol.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.