ActivityPub + Friendica Results in A valid URL was not provided. (https://socia

It seems that something in your setup is blocking content negotiation:

curl "https://blog.linux-help.org/2024/01/04/the-fediverse-is-here-sorta-kinda/" \
     -H 'Accept: application/activity+json'

This returns HTML instead of JSON and the same for your profile:

curl "https://blog.linux-help.org/author/psi-jack/" \
     -H 'Accept: application/activity+json'

This might be an issue with Cloudflare: https://dustinrue.com/2023/09/wordpress-activitypub-and-cloudflare/

Okay, that seems to have been W3 Total Cache’s Page Cache. I’ve disabled the page cache for this, and now it’s working. I also noticed W3TC had the option for using Object Caching so I disabled the Redis Object Cache and moved that to just W3TC as well, did several hits, as a logged in user, and non-logged in user, and validated the results.

Seems now, if specifically asking for it, it’s getting application/activity+json

This, however, does not resolve the original problem as it’s still happening.

At least one step further ??

I will check when I am back at the computer.

You can also try out WP super cache because it caches based on the accept header, so both versions will be cached properly there.

One more question: Have you enabled mod_sec on your server?

• This reply was modified 10 months, 3 weeks ago by Matthias Pfefferle.

Yep! Each step is helpful, no doubt. I will definitely check out WP Super Cache, because that sounds like a very good thing, specifically. I wasn’t overly impressed with having to configure redis on each part of W3TC anyway as if it’d be any different, and then still not getting the option to even setup which database or prefix.

And to your question, no, there’s no mod_security on my setup. The best I’m planning to do about stuff is separating uid/gid groups of each of the few web applications that have security concerns, so they are isolated down, and do log monitoring for IDS, and restore from backup if/when needed. My stuff is personal and not hypercritical.

Really do appreciate the help!

We had a similar problem: Friendica could reach a Mastodon instance that resided on the same server, but couldn’t follow its accounts.Our system engineer found a solution to the problem here:https://github.com/mastodon/mastodon/issues/20141#issuecomment-1307688586In our case there wasn’t the additional complication of Cloudflare’s CDN, but perhaps what was written there could help find your solution

It’s funny that you should mention that googlow. I actually thought about that as well, and at one point in time, did do the host hack of /etc/hosts to the same servers in each server, just to see, and nothing changed in that when I was testing. I can certainly try it again with the new changes that’s happened since but I’m betting the result will be the same. As it is I’m using Split DNS and internally, blog.linux-help.org and social.linux-help.org point to CNAME records resulting in lb.linux-help.org, which is the Virtual IP (VIP) for HAproxy which would result in it going there and immediately back.

Problem is. I’m only seeing the queries to WordPress’s wp-admin/friends, not anything coming out of WordPress, so I think this has more to do with a wordpress specific issue. Just WHAT I’m not so sure on.

Any further ideas on what’s wrong here?

So, I’m pretty sure now there’s something going on with the checks on the site it’s trying. Basically, from WordPress or this plugin, it’s literally never even reaching out to try since social.linux-help.org resolves, internally, to 172.17.2.110, which is an internal private IP address.

Why this is happening, and why it’s not going forth and trying, that’s a question of, what’s causing that? This plugin, or something to do with WordPress itself? I tried this exact same setup with WriteFreely with it’s native support for linking to ActivityPub and it had literally no issue. I changed my DNS setup a little bit, and made it so my internal name resolved to my external IP that is cloudflare, and routed accordingly, and literally no issue at all, it just worked, and I could see actual traffic all the way end to end.

So it was WordPress itself actually blocking access..

https://github.com/WordPress/wordpress-develop/blob/6.5/src/wp-includes/http.php#L529-L618

This URL details that internal IP addresses, in total, are being blocked by default, and the best way I could figure out to get around this issue was ultimately very simple. Create a custom plugin that, in my case, literally did the following:

add_filter( 'http_request_host_is_external', 'allow_my_lbhost', 10, 3 );
function allow_my_lbhost( $allow, $host, $url ) {
  if ( $host == 'social.linux-help.org' ) {
    $allow = true;
  } else if ( $host == '172.17.1.110' ) {
    $allow = true;
  }

  return $allow;
}

Once this custom plugin was loaded with this add_filter, I was in business, finally.