BUG: Domain mapping https issue with domain health check

Domain mapping is not checking to see if wp-admin is forced ssl or if the site is in ssl mode, and then making its referenced url be in ssl mode.

As a result there is no domain heath check status coming through and in the browser console there is the error explaining why:

https://networkdomain.com/blogname/wp-admin/tools.php?page=domainmapping was not allowed to display insecure content from http://networkdomain.com/blogname/wp-admin/admin-ajax.php?action=domainmapping_check_health&nonce=87BLAHBLAH&domain=mappedomain.com.

Using nginx on my server.

Please forward this bug to the developer for review, would like his thoughts.

Thanks.

  • Tyler Postle

    Hey Ben,

    Right now we usually give around the 5-10 point range. Unless you're sharing a custom plugin or something like that then it can be more 50+ range.

    We are actually completely restructuring our points system and including more rewards, this will be happening within the next few months hopefully :slight_smile: your points will transfer over and I think it will add more value to the points you have. Stay tuned for more info on that. Thanks again for your participation and interest in helping out.

    Cheers,
    Tyler

  • Sajid

    Hi @Ben,

    Hope you are doing good today :slight_smile:

    Thanks for more details regarding this matter. I have heard back from developer and he provided a beta version with fix.

    Please download the attached beta version, install and let us know how it goes.

    Please bear in mind that its a beta version so MUST take backup of your existing site first before installing it.

    Take care and have a nice day :slight_smile:

    Kind Regards,
    Sajid J

  • Ben

    Just tested it on my smaller network....guess I'm the QA guy...?

    Health status issue still not working.

    Here are the console errors that should help the developer @Sam

    Mixed Content: The page at 'https://mynetworkdomain.com/userblog/wp-admin/tools.php?page=domainmapping&tab=mapping' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://mynetworkdomain.com/userblog/wp-admin/admin-ajax.php?action=domainmapping_check_health&nonce=XXXXXX&domain=www.mappedomain1.biz'. This request has been blocked; the content must be served over HTTPS.send @ load-scripts.php:5
    load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=4.4.1:5 Mixed Content: The page at 'https://mynetworkdomain.com/userblog/wp-admin/tools.php?page=domainmapping&tab=mapping' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint

    2nd error:

    'http://mynetworkdomain.com/userblog/wp-admin/admin-ajax.php?action=domainmapping_check_health&nonce=XXXXXXdomain=www.mappedomain2.com'. This request has been blocked; the content must be served over HTTPS.send @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils&ver=4.4.1:5

    Lets get this right...and not have me be doing free QA for WPMU dev, this should be @James Farmer

    or @Timothy Bowers on this...not paying customers. Lets get this right.

  • Sajid

    Hi @Ben,

    Hope you are doing good today :slight_smile:

    Thanks for testing it on your environment. I talked with the developer and he said, he got it fixed on his environment and also two of our QA guys tested on their environments.

    But it happens and vary's from site to site and server to server.

    Any way, I really appreciate that you took time for testing and reporting it back, sending some points your way for appreciation.

    I have passed your feedback to developer, he is working on it and we will release the new version soon.

    Take care and have a nice day :slight_smile:

    Kind Regards,
    Sajid J

  • Ben

    @Sajid

    We all gotta get on the same page here...

    ... @Sam while I love his ideas and creativity, he is not testing in the NGINX environment with https and I'm guessing neither are the other two developers that are checking his work..I don't get it.

    The way https is handled in this environment differs I am guessing. It also caused issues in MarketPress.

    Developer @Hoang Ngo came through like a super hero and has created various hot fixes for https ...so perhaps we should get @Hoang Ngo to share with @sam what he has been doing for this various fixes so that the same mistakes aren't repeated...?

    Just a management thought from a customer. I know I sound angry and arrogant...and I know programming is hard (i'm a programmer) but these are really things that should be done before ever reaching the end user like myself. This isn't free open source software, this is paid software. If it were free, then I would need to keep my expectations a little more in check.

    And in addition, when the same issues keep repeating them selves, they need to be logged so that they are caught before the next software releases. Its the job of @Timothy Bowers to be doing this...not a paying client. And if a paying client is doing this, there should be some form of real compensation and gratitude, acknowledgement, transparency and change towards trying to fix these problems.

    Just my 2 cents.

  • Tyler Postle

    Hey there Ben,

    The version Sajid sent you fixes the issue for me; however, I'm not on an nginx environment either. I'll pass that info onto Sam to make sure it is fixed before it is officially released. As Sajid mentioned, this is an RC, it's still being tested and is not the official release.

    It's @Timothy Bowers job to be logging and managing QA? I will let him know :wink:

    Thanks for your feedback Ben! We will post back here when the final release is officially pushed out.

    Cheers,
    Tyler

  • Ben

    @@PatrickTyler Postle

    It's @Timothy Bowers job to be logging and managing QA? I will let him know :wink:

    I know that comment wasn't meant to be condescending...but crap man...the amount of bugs and poor performance with marketpress/pro-sites is kinda ridiculous to ignore, and he's the one ultimately responsible for finding the bugs and performance issues before they get to the customers..and fixing them...not me...right?

    @Sam you need to get an NGINX set up to test on. Try http://www.digitalocean.com its cheap.

  • Tyler Postle

    Just to be clear Ben, as I don't want my above sarcasm to be taken the wrong way. @Timothy Bowers has been coordinating with the QA team and the developers to help get your issues sorted out. He's been dealing with his Uncle's death this past weekend which is why you may not have heard from him as much.

    I'm the support team lead here and have been communicating with Sam on this as well and helping test. I'll make sure it is tested on an nginx environment as well, as I mentioned above, so that is sorted out in the official release :slight_smile:

  • Ben

    Again...I am a busy guy and all my debugging is taking away from other projects as I'm debugging...this should help @Sam

    Review the file: classes/Domainmap/Render/Site/Map.php

    Review the following function:

    public static function render_health_column( $domain ) {
                    $health_link = add_query_arg( array(
                            'action' => Domainmap_Plugin::ACTION_HEALTH_CHECK,
                            'nonce'  => wp_create_nonce( Domainmap_Plugin::ACTION_HEALTH_CHECK ),
                            'domain' => $domain,
                    ), set_url_scheme(  admin_url( 'admin-ajax.php' ), domain_map::get_mapped_domain_scheme( $domain ) ) );

    There is a problem here....the variable $domain is going to be the mapped domain and NOT site network domain... when you are grabbing the admin_url your are switching the url scheme to the mapped domain...there's one of problems...hopefully that helps him so he can expedite the full fix. Its not an NGINX problem.

    In addition i don't understand the use of: set_url_scheme in this scenario.

    AND if you wanted to use set_url_scheme, you could also check to see if you should be forcing ssl with: force_ssl_admin()

    This problem should be visible to anybody testing a multi-site with https forced for admin...I'm guessing this isn't your test case scenario...it should be as this should be a set up for every responsible wordpress multi-site admin...are you and your testers testing in a multi-site environment, with SSL forced for the admin functionality?

    @Timothy Bowers has been coordinating with the QA team and the developers to help get your issues sorted out

    No disrespect, but the problem here is there seems to be some sort of general arrogance or disconnect that these issues I am finding (hence why they don't seem to be getting fixed very quickly) are isolated to me... I believe my set up should be the most common use case for pro-site, domainmapping, marketpress setup: NGINX, MULTISITE, SSL, FORCE SSL ADMIN.

    There shouldn't be a single responsible site admin doing admin functionality without https in a multi-site. And since it is very time consuming to set up https per site, generally there would be one ssl certificate for the network where all the admin functionality would run through.

    Again...paying customer...I shouldn't be the guy giving the directions here on a fix. Lets get this right please.

  • Ben

    Follow up for @Sam

    When changing that

    $health_link
    to an ssl url, it removes the initial console errors...however it will uncover other errors and cause full on timeouts on the server. (so people out there don't attempt to change the code as modifications I am suggesting only help reveal another error that has more serious consequences)

    Going through the server logs, this error seems to pop up a bunch:

    2016/01/21 05:03:01 [error] 18963#0: *2783 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXX.XXX.XXX.XX, server: http://www.mymappedomain.biz, request: "GET /wp-admin/admin-ajax.php?action=domainmapping_heartbeat_check&check=e41bXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX44f5fcf6 HTTP/1.0", upstream: "fastcgi://unix:disappointed:var/run/php5-fpm.sock", host: "www.mymappedomain.biz"

  • Ben

    MORE debugging:

    IF a customer first time enters their mapped domain name with https it will show valid (even if https doesn't exist)

    IF a customer firs time enters their domain without http then it will have the spinny thing.

    IF a customer who first time put their domain name with http deletes their domain name and then re-enters their domain name with https it will still only be showing as entered with http and have the spinny thing

    IF a customer who first time put their domain name with https deletes their domain name and then re-enters their domain name with http it will still only be showing as entered with https and will show as valid (even though their domain doesn't have an ssl certificate)

    In addition, that heart beat check is becoming a big slow down in the server, it seems to be process that keeps repeating itself till timeout. I have to stop the nginx server, then restart it to get rid of the repeating process. The process seems to start up again if I visit the domain mapping page.

  • Ben

    So upon more review...this is pretty serious issue. There seems to be some sort of variable set as now anytime i go to the domain mapping the error i mentioned goes off and completed overloads my server to where i need to close the domain mapping pages (i'm guessing there is some ajax call running in the background) and then have to restart my server...so hope you guys are taking this bug serious! Thanks.

  • Ben

    When a user goes to the domain mapping area, this is the function called that is failing:
    In the file: classes/Domainmap/Render/Site/Map.php

    public static function render_health_column( $domain ) {
                    $health_link = add_query_arg( array(
                            'action' => Domainmap_Plugin::ACTION_HEALTH_CHECK,
                            'nonce'  => wp_create_nonce( Domainmap_Plugin::ACTION_HEALTH_CHECK ),
                            'domain' => $domain,
                    ), set_url_scheme(  admin_url( 'admin-ajax.php' ), domain_map::get_mapped_domain_scheme( $domain ) ) ); // http being set up a the health link which will fail because the server will rewrite that link to include https
    
                    $health = get_site_transient( "domainmapping-{$domain}-health" ); // I don't believe this gets set properly ever
    
                    $health_message = __( 'needs revalidation', 'domainmap' );
                    $health_class = ' domainmapping-need-revalidate';
                    if ( $health !== false ) {;
                            if ( $health ) {
                                    $health_class = ' domainmapping-valid-domain';
                                    $health_message = __( 'valid', 'domainmap' );
                            } else {
                                    $health_class = ' domainmapping-invalid-domain';
                                    $health_message = __( 'invalid', 'domainmap' );
                            }
                    }
                    ?><a class="domainmapping-map-state<?php echo $health_class ?>" href="<?php echo esc_url( $health_link ) ?>" title="<?php _e( 'Refresh health status', 'domainmap' ) ?>"><?php
                            echo $health_message
                    ?></a><?php
            }

    Lets look at the function that is using set_site_transient, the function set_valid_transient:

    Further review of the file: classes/Domainmap/Module.php

    I find the following functions:

    protected function _validate_health_status( $domain ) {
                    $check = sha1( time() );
    
                    switch_to_blog( 1 );
    
                    $scheme = self::get_mapped_domain_scheme( $domain );
    
                    $ajax_url =  $scheme ?  set_url_scheme( admin_url( 'admin-ajax.php' ), $scheme ) : set_url_scheme( admin_url( 'admin-ajax.php' ), "http" ); //even though this admin url is being forced into http here, at the server level this will rewrite http to https because admin_url has the wp-admin in its path
                    $ajax_url = str_replace( parse_url( $ajax_url, PHP_URL_HOST ), $domain, $ajax_url );
                    restore_current_blog();
                    $response = wp_remote_request( esc_url_raw( add_query_arg( array(
                            'action' => Domainmap_Plugin::ACTION_HEARTBEAT_CHECK,
                            'check'  => $check,
                    ), $ajax_url )), array( 'sslverify' => false ) );
    
                    $this->set_valid_transient( $domain, $status ); // I don't think status is ever going to be set to anything
                    return $status;
    
            }

    And then this points to:

    protected function set_valid_transient( $domain, $status = null ) {
                    $valid = $status;
                    if( is_null( $status ) ) {
                            $valid = $this->_validate_health_status( $domain ); //is this the beginning of an infinite loop?
                    }
                    set_site_transient( "domainmapping-{$domain}-health", $valid, $valid ? 4 * WEEK_IN_SECONDS  : 10 * MINUTE_IN_SECONDS ); // are we ever getting here...or just timing out from an infinate loop before this is ever reached.
    
                    return $valid;
            }

    Which then points back to the first function because $status is never set to anything...this could be the explanation for the server slow down when it actually has the right url to go to?

    I believe somewhere in here is the issue, I might not be following the logic properly, so it would be nice if the developer can review and give a response so that this can be fixed and then we can move on to getting cross domain cookies working for the main network domain and a mapped domain with stripe.

    Thanks.

  • Tyler Postle

    Hey Ben,

    I spoke with Sam earlier and he's actually developing on nginx. Says the fix he implemented is working for him. Could you enable support access so we can have a look at your DM settings?

    You can grant support access via WPMU DEV > Support > Support Access > Grant Support Access.

    Sam will be looking at this thread tomorrow as well to go over the info you've provided. Thanks for the debug info.

    Look forward to hearing back.

    Cheers,
    Tyler

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.