Failing DC SSO connection slowing down the admin with a timeout

I’ve set up Discourse Connect SSO using the official plugin, so my WP users log into Discourse without registering another user over there. It all works fine, except every single WP dashboard (admin area) request is slowed by 10s due to a timeout I’ve discovered only via Query Monitor plugin.

https://{our-forum-address}/site.json cURL error 28: Connection timeout after 10001 ms

WPDiscourse\Admin\MetaBox->discourse_request()
wp-content/plugins/wp-discourse/lib/plugin-utilities.php:516
WPDiscourse\Admin\MetaBox->get_discourse_categories()
wp-content/plugins/wp-discourse/lib/plugin-utilities.php:273
WPDiscourse\Admin\MetaBox->setup_options()
wp-content/plugins/wp-discourse/admin/meta-box.php:49
do_action('admin_init')
wp-includes/plugin.php:517

Plugin: wp-discourse

Even if it worked, why is there a need for a call like this in the first place? How can I disable it?

Forum and site are on separate servers. There is no Cloudflare. SSL is letsencrypt. It didn’t have this problem on staging. I moved to live, created a new API key and secret, trying to resolve this but it didn’t work.

The plugin says You are not connected to Discourse. Check that your connection settings are correct. If the issue persists, enable connection logs and check Logs. …but I am, as users are able to seamlessly log in to the forum by just clicking on a link containing its address.

The logs in WP say:


[2024-10-31 10:54:47] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""}

I thought that weird WP security thing cripples it, so I added this but no joy either:


add_filter('http_request_host_is_external', [$this, 'mark_discourse_api_url_external'], 10, 3);

function mark_discourse_api_url_external($is_external, $host, $url)
{
	if ($host === "{our-forum-address}") {
		return true; // Allow the request by indicating the host IS external
	}

	return $is_external;
}

Hey there @Firsh,

That call to your /site.json is needed for the Wordpress plugin to retrieve information about your Discourse.

That mean’s you’re not properly connected, and even if things seem to be working, I wouldn’t count on them to keep working.

This is what we need to focus on. Could you share what type of key you created? For reference please make sure you’re following the guidelines about this here:

2 Likes

I don’t think it’s the key. I tried with the staging site’s key beforehand, and the new one says “never used.” When I try a test call wp_remote_request to my forum’s homepage, that also timeouts. I set it up for “every user” and “global”.

Yeah but why all the time on every unrelated admin page? Once when needed would be enough. I tracked down where it comes from and it’s function get_discourse_categories() and this is hardcoded into add_action( 'admin_init', array( $this, 'setup_options' ) ); I don’t want my WP to know about categories on the forum, I’m not using any publishing/commenting features, I just need the login, which already works.

I also made a request to the forum homepage using wp_remote_request() and that also timeouts. Other random sites are accessible.

I understand you feel the request to /site.json is unnecessary, however without a successful connection to your Discourse the Wordpress plugin isn’t going to work reliably for you, so we should figure out why that’s not working regardless.

  1. Can you think of any other difference between your staging and production environment?
  2. Could you share the WP Discourse log meta files of your staging and production instances?
  3. Could you share links to your Wordpress and Discourse instances?
1 Like

Yes but it’s a private members-only site and forum in Hungarian.

Forum: https://forum.intelligensbefektetok.hu/
Site: https://intelligensbefektetok.hu/

My staging was an exact copy made manually, although running in Docker in a VM. Prod is not managed by me, and have no idea what kind of hosting it is, but we never had any problems and it was quite fast before this.

I tried just now:

  • The sslverify = false option in discourse_request function
  • And created a CNAME (alias) on Cloudflare on another one of my domains to point to the forum’s host behind the scenes (“better” SSL and the host is different, to rule out some kind of loopback restriction in the firewall of the live site’s host): https://ibkforum.stateofbliss.us but it timeouts the same way, while testing requests from staging works fine. It redirects to the main site when not logged in.
  • I’m using this tiny plugin to check the requests: https://wphive.com/plugins/wp-remote-request-check/

object(WP_Error)#5757 (3) { [“errors”]=> array(1) { [“http_request_failed”]=> array(1) { [0]=> string(59) “cURL error 28: Connection timed out after 5000 milliseconds” } } [“error_data”]=> array(0) { } [“additional_data”:protected]=> array(0) { } }

  • Other WP sites; this forum; the live site when making a request to itself, all work fine.

Staging WP’s log:

[2024-10-31 13:09:08] connection.INFO: check_connection_status.valid_scopes  
[2024-10-31 13:09:19] connection.INFO: check_connection_status.successful_connection  
[2024-10-31 13:09:19] connection.INFO: check_connection_status.valid_scopes

Live site logs are the same as in my OP:

[2024-10-31 13:12:32] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""}

When loaded directly in the browser, this works:
https://forum.intelligensbefektetok.hu/site.json

Thanks for helping btw

Do you mean Wordpress production or Discourse production? Is it possible that there is something in your Discourse production environment that is performing redirects and / or changing (or stripping) headers in requests?

If you could share that meta files of both instances, that would help. Click “View Meta” in the “Logs” admin panel.

This is probably the fundamental issue. If your Wordpress is unable to see your Discourse at all, the connection is not going to work. If you’re able to easily test this connectivity, I’d keep doing that while making any tweaks to the network layer of your forum untill you get a 403 (i.e unauthorized).

My gut says that this is a network-layer issue, perhaps a redirect or firewall.

There is no staging Discourse, both sites use the same live Discourse (same user IDs, etc). I asked about this in another thread and it should be fine. The network layer of the forum is really simple, hosted on Hetzner, official Docker thing in a VPS, and the forum has barely been used or customized beyond some visuals. I’m not aware of any settings that would prevent it from being reached. I created a ticket at the WP hosting company to see if they can see why the connections fail as I’m more worried about their unusual setup.

What’s interesting to me is that the mere fact that the forum can reach WP (not the other way around) is “enough” for a working SSO. Except for logging out users from the forum.

Logs (live site downloads a 0-byte ZIP).

Yeah, I’d wait for the outcome of this first, otherwise we might be spinning our wheels here. The basic question is why a standard WP request can’t reach your forum.