- The Cloudflare Fonts option ID has changed. This addresses that (it's what I get for giving the ability to toggle options that Cloudflare has deemed "beta"... they are subject to change).
- Added a sanity check so if future option IDs change, it won't throw an error (along with not being able to change them). Instead, that option won't change until the ID is updated.
- Completely revamped how the bot management API is handled
- Added Super Bot Fight mode settings as controllable options (options enabled/available to be toggled will ultimately depend on what your Cloudflare plan allows):
- Likely Automated
- Definitely Automated
- Verified Bots
- Static Resource Protection
- Optimize For WordPress
- JavaScript Detections
Cloudflare changed API results for bot management, but only for paid plans. This addresses that.
- Added support for new Cloudflare setting: Speed -> Optimization -> Content Optimization -> Cloudflare Fonts
- When using "Easy config", set "Security level" to "Essentially off" (was set to "Medium" before)
- Easy config enables Cloudflare Fonts
IMPORTANT for existing users: New functionality requires 1 additional API permissions in order to use the new function. You can go to your Cloudflare API Tokens, edit the token you have and add the following permission:
At this point, you should have a total of 19 permissions for your API token.
Account.Billing: Read
Made a fairly substantial internal change to the guest page caching system... it no longer needs to do a quick AJAX request to fetch a CSRF token for guests. Instead we are using the
- Added sanity check to make sure attachment data exists when using presigned URLs for R2 attachments (helpful in certain cases when using XFMG).
- Added ability to use Token Authentication system for attachments stored in R2 (needs new permission... see above). This only works for zones that are not on the Free tier (which is why the billion permission is needed to check if the zone is on a paid plan or not).
- Update Chart.js to v4.4.0
- All JavaScript has been rewritten to be "native" (does not use jQuery) in preparation for removal of jQuery in XenForo 2.3.
- When using guest page caching, no longer try to fetch a new CSRF token for the user with a quick synchronous AJAX request (using Sec-Fetch-Site HTTP request header [a more modern replacement for CSRF tokens])
Sec-Fetch-Site
HTTP request header which is more or less supported by all browsers now (CSRF tokens aren't really needed anymore).
Was going down the path of trying to do a synchronous AJAX request in native JavaScript (rewriting for XF 2.3) and then trying to handle a bunch of one-off situations where XenForo is injecting CSRF tokens into certain GET requests because they are using GET to mutate user state for some reason... just was getting too kludgey and cumbersome. And since CSRF isn't really needed anymroe these days, I decided to take the cleaner/simpler route (which will also make sites faster). Just use Sec-Fetch-Site instead of CSRF... problem solved.
Maybe it's worthwhile to check out the suggestion that XenForo does away with CSRF in it's core: https://xenforo.com/community/threa...ion-cloudflare-full-html-page-caching.202315/
Augh! the new option group wasn't included in the 1.7.2 build (sorry)...
This fixes that.
- Moved Cloudflare options from
External service providers
to their own Options page- New option (advanced): Show attachment data errors in server error log
- Add sanity check when using R2 with presigned URLs and users are allowed to upload audio/video media
The presigned URL thing is particularly interesting... a remote storage system like R2 has your server checking user permissions to see if a user can view something, then it makes an API call to fetch the file/object and then passes that through to the user.
- Can use R2 for storage without site being a domain/zone in Cloudflare
- Made change to XenForo's attachment data entity to be more efficient (normally XenForo checks if an attachment exists before making an additional call to actually get it). This will reduce an API call for every attachment view because we don't need to check if the attachment exists (we know it does already because we have a record of it in attachment data).
- Added new option: Use presigned URLs for attachments stored in R2 (allows attachments stored in R2 to be viewed directly by the user, rather than you server needing to download the attachment to pass it through to the user)
As an example, if you have a 10MB attachment, your server first needs to download 10MB and then it sends that 10MB to the end user (so there's the time it takes to download the attachment from R2 and as well as 20MB total bandwidth happening on your server... 10MB in, then 10MB out). With presigned URLs, your server does the permission check and then if the user has permission to view the attachment, the user is redirected to a unique URL that expires in 60 seconds to fetch the attachment. This means attachments are viewed faster for end-users and your server isn't wasting bandwidth passing it through to the user.
Presigned URLs that expire and can't be changed by users is done with cryptographic signing (hence the name, presigned URLs).
Fix for issue when trying to enable guest page caching (ends up in a loop). Only needed if you don't have guest page caching enabled and you want to enable it.
We use essential cookies to make this site work, and optional cookies to enhance your experience.