XF 2.3 Service worker path

[webbouk]

A few of our users, predominantly using iPhone/iPad and Safari, have been experiencing issues accessing our forums with issues such as pages not loading and being requested to 'Reload' the page, or style sheets not loading.
Despite them clearing their caches and history, making several changes to Safari permissions, etc, the issue is still ongoing.
The issues however aren't regular, more sporadic. Everything works for a while and then it re-occurs with no pattern occuring.

The issues have been happening over the past month during which time various changes have been made to our Cloudflare rules to combat bot attacks, none of which should impact these specific users. Safari itself had been updated, which coincided with the start of the issues, and our hosts made several changes to protect their networks during the recent issues with cPanel, all of which have now been resolved.

Having exhausted my knowledge and used AI to give insights and recommendations to resolve the issue, one such suggestion was that Safari can have an issue with XenForo's service worker, especially on large forums, which can cause the issues being reported. The recommendation was to create a skip rule within Cloudflare to see if this resolves the issue.
However, from what I understand, Xenforo doesn't use a file for the service worker as it is created dynamically. One such suggestion was to use the path service-worker.js

I've used this path within a rule but not sure if it is correct, or even if it is doing anything.... expression: (http.request.uri.path contains "service-worker.js")

Any advice or suggestions would be appreciated

 

[tajhay]

A few of our users, predominantly using iPhone/iPad and Safari, have been experiencing issues accessing our forums with issues such as pages not loading and being requested to 'Reload' the page, or style sheets not loading.
Despite them clearing their caches and history, making several changes to Safari permissions, etc, the issue is still ongoing.
The issues however aren't regular, more sporadic. Everything works for a while and then it re-occurs with no pattern occuring.

The issues have been happening over the past month during which time various changes have been made to our Cloudflare rules to combat bot attacks, none of which should impact these specific users. Safari itself had been updated, which coincided with the start of the issues, and our hosts made several changes to protect their networks during the recent issues with cPanel, all of which have now been resolved.

Having exhausted my knowledge and used AI to give insights and recommendations to resolve the issue, one such suggestion was that Safari can have an issue with XenForo's service worker, especially on large forums, which can cause the issues being reported. The recommendation was to create a skip rule within Cloudflare to see if this resolves the issue.
However, from what I understand, Xenforo doesn't use a file for the service worker as it is created dynamically. One such suggestion was to use the path service-worker.js

I've used this path within a rule but not sure if it is correct, or even if it is doing anything.... expression: (http.request.uri.path contains "service-worker.js")

Any advice or suggestions would be appreciated

I have been having this issue for a few weeks too.

 

[webbouk]

It looks like I've managed to solve the issue with a suggestion and the help of AI ....

It was suggested that it was perhaps a CORS issue from one of the APIs that Safari is freaking out about.

Testing locally on a Apple device....

Open Safari.
Go to Safari > Settings (or Preferences) and select the Advanced tab.
Check "Show Develop menu in menu bar".
Click the newly visible Develop menu in the top bar and select "Disable Cross-Origin Restrictions"

Which appeared to resolve the issue on that device.

I then looked to resolve it for all devices at Cloudflare's end and did a search for the issue with Cloudflare and Xenforo in the search criteria and came across this:

CORS and cross-origin cookie restrictions in Safari often break XenForo AJAX requests, throwing "Cookies are required" errors or blank page loads. Safari enforces strict Cross-Origin Resource Sharing rules, differentiating between HTTP and HTTPS, and subdomains like www...

So what seems to have been happening is that the domain was in Cloudflare as mydomain.com
Yet the Xenforo domain in ACP>Setup>Options>Basic Options was set as www.mydomain.com
Changing the domain in the ACP, removing www, wasn't feasible as it would log everyone out.

AI gave this explanation:
The CORS and cookie errors you are seeing on XenForo 2.3.10 without subdomains are caused by a known conflict between how Safari enforces CSRF tokens, how XenForo 2.3 handles JavaScript optimization, and how Cloudflare caches HTML.
Safari aggressively drops or refuses to validate security tokens when it detects mismatches between cached static layouts and live dynamic assets. When a Safari user loads a Cloudflare-cached page, they receive an expired CSRF (Cross-Site Request Forgery) token. When they click a button or submit a form, the AJAX request fails

If your site loads as https://domain.com but your XenForo options or config files are pointing to https://www.domain.com (or vice-versa), Safari will block the request under a strict CORS policy.


Further use of AI resulted in the following suggestions - all four steps to be completed:
To completely isolate your dynamic XenForo 2.3.10 layout from aggressive Cloudflare caching—ensuring Safari always pulls a fresh CSRF token—you need to build rules in your Cloudflare dashboard. By default, Cloudflare doesn't cache HTML or .php extensions, but if a global "Cache Everything" rule exists or if your origin server sends confusing headers, Safari will lock up.


1. Disable Edge Cache TTL in Cloudflare
If you have a Cloudflare Page Rule or Cache Rule set up to "Cache Everything," Cloudflare is caching the HTML of your forum pages along with old security tokens.

• Log in to Cloudflare.
• Navigate to Caching -> Cache Rules (or Page Rules).
• Ensure you are not caching HTML pages (.php files or your root paths) with a high Edge Cache TTL.
• Dynamic forum views must bypass Cloudflare's cache so Safari receives fresh CSRF tokens on every single page load. Only static assets (/js, /styles, /data) should be deeply cached.

Configure these rules in the following order to resolve the issue:

Step 1: Create a "Bypass Cache" Rule for Dynamic Pages
This rule forces Cloudflare to ignore your forum index, threads, and backend scripts, guaranteeing a direct hit to your server for real-time page builds.

1. Go to the Cloudflare Dashboard and choose your domain.
2. Navigate to Caching -> Cache Rules and click Create Rule.
3. Fill out the rule configuration:
   • Rule name: Bypass Cache for Dynamic XenForo HTML/PHP
   • When incoming requests match: Change the selection to Custom expression engine.
   • Click Edit expression and paste the exact line below:

(http.request.uri.path.extension in {"php"} or not http.request.uri.path contains ".")

(This targets .php files directly alongside root paths/URLs that don't have file extensions, like https://domain.com). [1]

• Under Then (Cache eligibility): Select Bypass cache.
• Click Deploy.

Step 2: Create an "Eligible for Cache" Rule for Static Assets
This rule optimizes speed by aggressively saving and offloading javascript, styles, and data layers to Cloudflare's edge network.

1. Return to the Cache Rules index page and click Create Rule.
2. Fill out the configuration:
   • Rule name: Deep Cache XenForo Static Assets
   • When incoming requests match: Set it to Custom expression engine.
   • Click Edit expression and paste the following:
     
     

     (starts_with(http.request.uri.path, "/js")) or (starts_with(http.request.uri.path, "/styles")) or (starts_with(http.request.uri.path, "/data"))

   • Under Then (Cache eligibility): Select Eligible for cache.
   • Under Edge TTL: Select Override origin -> Set TTL to 1 month (or your preferred long duration).
   • Under Browser TTL: Select Respect origin
   • Click Deploy
     
     
     Note:
   • Cloudflare evaluates Cache Rules sequentially from top to bottom.
     • On your main Cache Rules summary screen, verify that your Bypass Cache rules sit above any broad rules or "Cache Everything" rules you might have built in the past.
     • If you have existing legacy Page Rules trying to "Cache Everything" for the entire domain (://domain.com), delete or disable them, as they will override these newer granular controls.

Step 3: Clear the Faulty State

1. Navigate to Caching -> Configuration.
2. Click Purge Cache -> Purge Everything to drop the broken validation strings from Cloudflare's network edge.

I hope this helps if you're experiencing issues with Safari and your forum.
Please follow the instructions explicitly. I'm not an expert in Cloudflare so I cannot offer any further advice other than what you see.

Please feel free to add or suggest edits.
I've used this and it works.

 

[tajhay]

Brilliant, thank you! Ill test the above out later tonight and ask my users impacted (i was never able to replicate it)

 

[webbouk]

I've updated post #3 and it seems to be working for the affected Safari users