• Resolved songiuno

    (@songiuno)


    Hello,

    I am unable to connect/sync sites one way. Site A fails test sync to site B. Site B passes sync test to site A. I’ve looked thru any previous support posts that might answer my issue but have not found any. The error I get on site A is: Error contacting the remote site: “an undefined error occured. Please make sure the address is correct and try again. On the remote site, please make sure the plugin is activated and that the permalinks are up to date by visiting the permalinks settings page”. I have copmared/verified on both sites the address settings in WP settings/general/wordpress address, the database wp_options home values. I verified security settings as the same and assume them to be verified the same since Site B tests good to Site A.

    Site A activity logs:

    2020-07-22 19:30:10 – Info – Renewing token for https://www.siteB.net/wpblog
    2020-07-22 19:30:11 – Warning – Failed to renew token for https://www.siteB.net/wpblog – retrying…
    2020-07-22 19:30:12 – Alert – Failed to renew token for https://www.siteB.net/wpblog
    2020-07-22 19:30:12 – Alert – Failed to renew token for https://www.siteB.net/wpblog
    2020-07-22 19:30:12 – Alert – Error contacting the remote site: an undefined error occured. Please make sure the address is correct and try again. On the remote site, please make sure the plugin is activated and that the permalinks are up to date by visiting the permalinks settings page.

    Site B activity logs is clean.

    I’m sure the failed to renew token is telling me what the problem is but I don’t understand, as a novice at WP.

    Any help?

    • This topic was modified 4 years, 4 months ago by songiuno.

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 17 total)
  • Plugin Author Alexandre Froger

    (@frogerme)

    Hello @songiuno ,
    What I can see from the logs is that the token failed to be renewed. This is the actual issue right there, you’re right. The initial handshake to establish further communication failed, and that can come from several sources, ranging from a possible bug in the plugin (in which case I would need to be able to replicate it with more information) to the specific server setup (response time between servers being in general the most likely culprit).

    Let’s see if I can get some more insights first:
    – Are the sites on the same server?
    – If not, can the server on which site B is installed ping site A’s URL in ssh?
    – Are they both installed inside a subdirectory (as /wpblog seems to indicate for site B at least)?
    – Is the IP Whitelist being used?

    • This reply was modified 4 years, 4 months ago by Alexandre Froger. Reason: typos
    Thread Starter songiuno

    (@songiuno)

    Yes they are on the same VPS server according to my hosting service. Yes, both are inside a subdirectory on each site. I’m not using the IP Whitelist since neither site is assigned static IP. Should I? I have not noted how often IPs for the sites are reassigned.

    Plugin Author Alexandre Froger

    (@frogerme)

    Hi @songiuno ,
    I was asking to know more about the environment in which the problem happened. I can now try to replicate as closely as possible in my own. Don’t worry for now about the IP Whitelist (the IP address of a website does not change over time without notice from the hosting service, and not often in any case, because it’s tied to DNS A records, but that’s beside the point – I mentioned it to eliminate this as the potential source of the issue).
    I’ll post back here if there is progress with my tests!

    Plugin Author Alexandre Froger

    (@frogerme)

    So, I just installed 2 WordPress sites (vanilla, no plugin or theme) on the same server, https://sub.domain.tld/folder1 and https://sub.domain.tld/folder2

    Everything did work as designed

    Now, the way to troubleshoot further involves editing the code of the plugin to output the content of what the site receives when the alert message is displayed. At this point, I must disclose that if you are not comfortable with editing the PHP files, I can only suggest you involve a programmer who can help you.

    I wrote the code for you:

    
    Wprus_Logger::log(
    	array(
    		'message' => 'Content received from remote site when renewing token: ', 
    		print_r( $body, true )
    	),
    	'info',
    	'db_log'
    );
    

    It should be added between line 910 and 911 of wp-content/plugins/wp-remote-users-sync/inc/api/class-wprus-api-abstract.php ; the resulting get_remote_token( $payload ) method should then look like below:

    
    /**
     * Renew the security token for a specific payload
     *
     * @param array $payload The payload to send to the remote site
     * @return array|bool The security token information on success - <code>false</code> on failure
     */
    protected function get_remote_token( $payload ) {
    
    	if ( self::$can_request_token ) {
    		$timeout = apply_filters( 'wprus_request_token_timeout', 1 );
    
    		// translators: %s is the url of the caller
    		Wprus_Logger::log( sprintf( __( 'Renewing token for %s', 'wprus' ), $payload['base_url'] ), 'info', 'db_log' );
    	} else {
    		$timeout = apply_filters( 'wprus_request_token_retry_timeout', 5 );
    	}
    
    	$token_info = false;
    	$response   = wp_remote_post(
    		trailingslashit( $payload['base_url'] ) . 'wprus/token/',
    		array(
    			'body'     => array(
    				'wprusdata' => $this->encrypt_data( $payload ),
    			),
    			'compress' => true,
    			'timeout'  => $timeout,
    		)
    	);
    
    	$body = wp_remote_retrieve_body( $response );
    
    	if ( $body && 200 === wp_remote_retrieve_response_code( $response ) ) {
    		$token_info = json_decode( $body, true );
    	} elseif ( self::$can_request_token ) {
    		Wprus_Logger::log(
    			sprintf(
    				// translators: %s is the url of the caller
    				__( 'Failed to renew token for %s - retrying...', 'wprus' ),
    				$payload['base_url']
    			),
    			'warning',
    			'db_log'
    		);
    
    		self::$can_request_token = false;
    		$token_info              = $this->get_remote_token( $payload );
    	}
    
    	if ( false === $token_info && ! self::$can_request_token ) {
    		Wprus_Logger::log(
    			sprintf(
    				// translators: %s is the url of the caller
    				__( 'Failed to renew token for %s', 'wprus' ),
    				$payload['base_url']
    			),
    			'alert',
    			'db_log'
    		);
    
    		Wprus_Logger::log(
    			array(
    				'message' => 'Content received from remote site when renewing token: ', 
    				print_r( $body, true )
    			),
    			'info',
    			'db_log'
    		);
    	}
    
    	return $token_info;
    }
    

    After modifying the code, when performing a test from the plugin admin page, your logs would then output a message like below in case of success:

    
    2090-06-30 19:31:05 - Info - Content received from remote site when renewing token: 
    		Array
    (
        [0] => {"nonce":"5f0d796eee88828255ba8855907981ba5","expiry":1588889265}
    )
    

    After performing the test, please let me know the content of the log (please DO edit the value of the nonce if it appears!), and feel free to remove the extra code added to the get_remote_token( $payload ) method.

    Thread Starter songiuno

    (@songiuno)

    This may make a difference, but let me clarify. Both my site A and site B are on the same hosted VPS server, but different domains, sitea.com and siteb.com. So domains are different and not different subfolders of the same domain. But same managed VPS server.

    Does that make a difference in the approach to troubleshoot or should I go ahead and follow your code edits?

    Thread Starter songiuno

    (@songiuno)

    Hoping I followed the code insertion correctly to obtain the proper test results, this is what I got on site A, the site that fails test. Site B appears to have no issues and no output other than successful test.

     2020-07-23 21:29:33 - Info - Content received from remote site when renewing token:
    
    		Array
    (
        [0] => 
    )
    
    Thread Starter songiuno

    (@songiuno)

    Let me paste the entire output, as more results were output after my above.

    ` 2020-07-23 21:29:33 – Alert – Error contacting the remote site: an undefined error occured. Please make sure the address is correct and try again. On the remote site, please make sure the plugin is activated and that the permalinks are up to date by visiting the permalinks settings page.
    2020-07-23 21:30:21 – Success – Access granted – https://www.myinnersanctum.net/wpblog
    2020-07-23 21:30:21 – Success – Ping received for activated action “Logout” from https://www.myinnersanctum.net/wpblog with remote IP 69.163.182.46 (incoming)
    2020-07-23 23:10:18 – Info – Renewing token for https://www.myinnersanctum.net/wpblog
    2020-07-23 23:10:18 – Warning – Failed to renew token for https://www.myinnersanctum.net/wpblog – retrying…
    2020-07-23 23:10:18 – Alert – Failed to renew token for https://www.myinnersanctum.net/wpblog
    2020-07-23 23:10:18 – Info – Content received from remote site when renewing token:

    Array
    (
    [0] =>
    )

    Plugin Author Alexandre Froger

    (@frogerme)

    Hi @songiuno !
    I am on Beijing time, so please forgive the delays. The fact that they are on different domains could be the source, but it difficult for me to ascertain at the moment (I did test with both same and different sub, domain and TLD actually).

    So, we are getting somewhere: the result confirms that the plugin on site A could not reach site B and get an answer it could use – it is not the plugin giving a false negative. Now we may be able to determine why that is so.

    The next step would be to edit the code again, and replace:

    
    Wprus_Logger::log(
    	array(
    		'message' => 'Content received from remote site when renewing token: ', 
    		print_r( $body, true )
    	),
    	'info',
    	'db_log'
    );
    

    with the following:

    
    if ( is_wp_error( $response ) ) {
    	Wprus_Logger::log(
    		array(
    			'message' => 'Renewing the token resulted in a WordPress error: ', 
    			$response->get_error_code() . ' ' . $response->get_error_message(),
    		),
    		'info',
    		'db_log'
    	);
    } else {
    	Wprus_Logger::log(
    		array(
    			'message' => 'Response received from remote site when renewing token: ', 
    			print_r( $response, true )
    		),
    		'info',
    		'db_log'
    	);
    }
    

    What we are doing here is check if the response from the remote site is an error object and display its code and message if it’s the case, or display the raw response for analysis otherwise.

    I suspect you may receive a result in the log similar to:

    
    cURL error 28: Operation timed out after 1000 milliseconds with 0 bytes received
    

    and then

    
    cURL error 28: Operation timed out after 5000 milliseconds with 0 bytes received
    

    This would mean that in both the first and second attempt, the connection between the two sites could not be established in time (or not reachable at all), and this would have more to do with your hosting, network, DNS, etc. In the case it’s just a timing issue, you could possibly put measures in place to mitigate the timeouts if this is indeed the issue (see the documentation for wprus_request_token_timeout and wprus_request_token_retry_timeout filters).

    But I’m getting ahead of myself ; let’s see the result first!

    Plugin Author Alexandre Froger

    (@frogerme)

    Hi @songiuno !
    I just noticed you posted the actual URL of your site (https://www.myinnersanctum.net/wpblog). I clicked on it, and my browser (Chrome) showed the following error: NET::ERR_CERT_AUTHORITY_INVALID.

    Unless this is not the actual URL and was just a placeholder for this forum, this indicates there is an underlying https related network issue, which is not related to WPRUS, but may very well affect communication between sites.
    Fixing that first may be the best way to get things working, or at least allow us to troubleshoot more accurately.

    Thread Starter songiuno

    (@songiuno)

    Aha, okay let me pursue that first then. Site B, the myinnersanctum.net site, is new and I have seen that invalid cert error after configuring security with my host. Sorry, let me work on fixing that.

    Thread Starter songiuno

    (@songiuno)

    Thank you Alexandre for catching that SSL certificate issue, that was the problem. Both sites test good and work now. My hosting support cleared it up. Thank you so much and apologize for your time spent and it not being the plugin at all.

    Plugin Author Alexandre Froger

    (@frogerme)

    @songiuno You’re welcome, glad it all worked out!
    Also, the debugging code I advised you to add gave me inspiration for better troubleshooting logs that I’ll include in the next version ;).

    Thank you for your patience, and please feel free to leave a review!

    Hey guys,

    So I followed this thread all the way to the bottom and I have the timeout issue. Also I know what causes it, the target site is running on my nas which is in the process of creating a large off-site backup so…
    I pasted the debug code above into the plugin and this is my output:

     2020-09-01 17:24:13 - Info - Renewing the token resulted in a WordPress error:
    
    		Array
    (
        [0] => http_request_failed cURL error 28: Operation timed out after 5000 milliseconds with 0 bytes received
    )
    	
    
    2020-09-01 17:24:13 - Alert - Failed to renew token for https://my.site.nl
    2020-09-01 17:24:13 - Info - Renewing the token resulted in a WordPress error:
    
    		Array
    (
        [0] => http_request_failed cURL error 28: Operation timed out after 1000 milliseconds with 0 bytes received
    )

    I’m hoping to increase the timeout period and would appreciate a (semi) permanent solution by editing the code. Can you point me in the right direction?

    Thanks!

    Plugin Author Alexandre Froger

    (@frogerme)

    Hi @paulbnl !

    Timeout after 5 seconds on retry is not a good sign for the connectivity between your 2 websites (at the server level). If the timeout is increased, it means a longer page load for the users, and degraded performances. It is recommended to troubleshoot the connectivity between the servers before resorting to such measure.

    If performances degradation is an acceptable trade-off, increasing that limit is done with the documented filters wprus_request_token_timeout and wprus_request_token_retry_timeout like so:

    
    add_filter( 'wprus_request_token_timeout', 'my_wprus_request_token_timeout', 10, 1 );
    add_filter( 'wprus_request_token_retry_timeout', 'my_wprus_wprus_request_token_retry_timeout', 10, 1 );
    
    function my_wprus_request_token_timeout( $token_timeout ) {
        return 5; // Default is 1
    }
    
    function wprus_request_token_retry_timeout( $token_retry_timeout ) {
        return 10; // Default is 5
    }
    

    This code would need to be placed in a custom plugin or your theme’s functions.php.

    Thank you @frogerme

    The performance of this site is not an issue, it is a dedicated subdomain for user management that has very low traffic.
    I put this in a code snippet and the timeout problems are gone.
    However it seems like there is something else failing quietely in the background now because if I change some data the action starts but there is no response.
    Sending site log:

    
    2020-09-02 10:46:40 - Info - Update action - firing action for username "[email protected]"
    2020-09-02 10:46:42 - Info - Metadata action - firing action for username(s) "[email protected]"

    Like it just gives up. If I stop the outgoing backup on the receiving end which frees up the internet connection then it works very smoothly again.
    Is there another timeout or wait period involved?
    If this issue is too much an edge case scenario I will make sure to only load my network like that at night, but if there is anything I can do debug or test this I am more than happy to try.

Viewing 15 replies - 1 through 15 (of 17 total)
  • The topic ‘Error connnecting Site A to Site B’ is closed to new replies.