Link to a discussion from another discussion randomly broken

CyberGene

I recently created a new tag on my forum and that tag is hidden from the main discussion list. I tagged a few existing discussions with that tag. I’ve also assigned view permissions for that tag to be for members, not public. Not sure if any of that is the reason or is not related, however I copied the URL to one of those discussions and posted it in another one that is not with the same tag, it’s a public one. Well, that link sometimes works, sometimes it fails with “The page you requested could not be found”. Here’s an example link (not real)

https://myforum.com/forum/d/1188-some-discussion-title/

When that link doesn’t work, I remove the trailing slash and it starts working but then stops again. Then I add back the slash and it starts working, then stops, then again. Same if the link has post number at the end of the URL. When it doesn’t work you have to change the post number to something else.

Any ideas? I cleared Flarum cache. I also purged CloudFlare cache.

Could it be a permission thing? I think in the past I’ve had problems with discussions that are not public and visible only to registered members. Could it be that requests sometimes get stripped from who’s the logged in user? Is that a cookie?

BTW, the more I think about it, the more I am convinced it’s related to the member-only permission and I’ve had that problem a lot in the past with our Politics tag but we haven’t used it for long time.

CyberGene

I’ve found a very old discussion with the same problem:
https://discuss.flarum.org/d/4937-404-not-found-error-due-to-members-only-permission-on-tag-bug/6

It’s marked as solved but if you read it carefully, it’s not actually solved and the reporter also thinks it’s a bug.

Can someone working on the core Flarum code and permissions clarify how it is determined that a user opening a discussion is actually a member? Is a cookie expected to be in the request? Or some ID that changes with each request? What could be wrong with that logic? Why would it occasionally assume a logged in user as not logged in and then again as logged in, without the user actually logging out and in? I’m absolutely sure that’s the root cause.

CyberGene

Seems I might have found what causes the issue but I cannot be really sure, so I will report again later. Basically, I could reproduce it pretty consistently:

Create a Flarum tag that has the "view forum" permission set to members (and not to everyone)
The above means that users that are not logged will not be able to see discussions with that tag and will receive the “The page you requested could not be found” error which is in fact 404 in the error console. That is expected.
Now if you log in with a user and try to open the same discussion URL, you might sometimes see the same problem. No matter how much you refresh it, it would give you that error for some time. After that it will fix itself. Or, if you modify slightly the URL by e.g. adding / at the end, or change the post number in the URL, the problem will disappear

That made me think it's some caching problem. I use CloudFlare but couldn't find anything that can be reconfigured there and I don't have any custom caching edge rules, etc.

Then I moved on to mine SiteGround hosting and I found that there are three types of caching there:

Nginx Direct Delivery. It was turned on. It's a bit weird, since my Flarum is hosted by the Apache, so it seems SiteGround use an Nginx facade that they have configured to do some caching before the Apache, or at least that's my understanding. I disabled it.
Dynamic cache - this is really fishy and I don't understand how exactly it works but they claim it caches dynamic pages, e.g. PHP, so that they cache the response and then the next user requesting the same PHP would get the cached response. Either I get it wrong, or it's a wrong idea in the first place but I really don't see how that may work at all. You must not cache a dynamic content generated through PHP... I don't know, maybe they also check whether the request writes in the DB and then assume that if the DB is unchanged, then they can cache the PHP result, or who knows what?! Anyway, it cannot be disabled. So, I searched if I can disable completely the caching and found out that they have a buried info in their FAQ that in order to disable caching, you have to put the following in your .htaccess file:

<IfModule mod_headers.c>
  Header set Cache-Control "private"
</IfModule>

However the above would make any Flarum response to be marked as private cache-control, which in turn will prevent CDN-s such as CloudFlare to cache static resource, it has to be applied only to non-assets.

Besides, with the standard installation of Flarum there's already a mod_header.c directive that fixes some proxy stuff, so to combine both and not apply private cache control on assets, the section becomes:

# Fix for https://httpoxy.org vulnerability
# Disable SiteGround cache for non-asset resource
<IfModule mod_headers.c>
  RequestHeader unset Proxy
  <If "%{REQUEST_URI} !~ /assets/">
    Header set Cache-Control "private"
  </If>
</IfModule>

Memcached which is disabled by default and I'm not sure if it can be used by Flarum.

I think by disabling 1 and 2 I may have solved the problem. I don't see the original issue anymore, at least in the last two hours.

BTW, it would be great if Flarum would not show 404 when anonymous users open these discussions. A 401/403 is the proper error code with a corresponding error page that would redirect to the Login page.

CyberGene

I think it was the SiteGround silly “dynamic” caching. I will mark my own reply to my own question as the “best answer”, feeling like a lunatic 🤡

luceos

CyberGene I'm glad it wasn't Flarum and just a caching layer 🙂 And excellently spotted!

CyberGene

I updated my own post above with edited instructions on how to not apply private cache-control to the assets folder, otherwise CDN-s (in my case CloudFlare) would not cache anything. As a side-note, private cache-control is a header that means the response should be cached only by the browser, and not by the server or CDN because it supposedly contains private data that should not be shared between different users.

I also read more about the dynamic caching of Siteground. It relies on response HTTP headers and would cache even PHP responses if it detects certain combinations. I think the problem is they developed that thing around Wordpress. However, some Flarum responses either have incorrect headers, or miss required headers, or the Siteground caching is buggy, but it seems that caching is applied on Flarum pages which have different permissions for different users and as a result when a non-authorized user opens a page he's not authorized to see, the 403 response gets cached and then authorized users would directly see the cached 403 response instead of seeing the discussion/post.

That is why, with the above .htaccess directive we forcefully mark every response (except for assets) as private (meaning the response can be different for different users, so only the browser of the user can cache it, and not servers that will share it between users).

I can confirm after a week now, that the initial issue has been resolved. Also, with my initial cache-control directive, I noticed drastic decrease of caching on CloudFlare which resulted in high load on my hosting server. However, after applying the cache-control on the non-assets (the latest edit in my previous post), the CloudFlare caching resumed to 30-50% caching as always.

As a final hint, you may want to create a CloudFlare page rule that sets Edge Cache TTL to a month for the following path: yourforum.com/forum/assets/* Edge Cache TTL: a month (adapt the URL, you may not have the /forum/ segment)