[DigitalPoint] App for Cloudflare 1.8.8

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:

• Account.Billing: Read

At this point, you should have a total of 19 permissions for your API token.

• 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])

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 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/

• 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

• 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)

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.

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.

IMPORTANT for existing users: New functionality requires 2 additional API permissions in order to use the new functions. You can go to your Cloudflare API Tokens, edit the token you have and add the following permissions:

• Account.Allow Request Tracer: Read
• Account.Intel: Read

At this point, you should have a total of 18 permissions for your API token.

Changes:

• Added ability to cache media attachments (both normal attachments and XF Media Gallery uploads) at network edge (images, video and audio attachments can be cached in Cloudflare data centers)
• Reorganized admin navigation (Cloudflare functions consolidated into a new Cloudflare section)
• Switched order of Network and Scrape Shield settings
• Added descriptions for each Cloudflare setting
• New option: Purge cache when post is created or deleted
• New Cloudflare Tools section:
  • HTTP request trace
  • IP address details
  • Domain details
  • WHOIS

• Fixed issue where you would get a Call to a member function getBody() on array exception instead of the intended HTTP response if an API call failed twice (it automatically does a retry if it failed once)
• When using guest page caching, decouple the purge cache mechanism from the http request (the purge cache action is sent to XenForo's job system)
• Show egress bandwidth when hovering over R2 class A or class B operation stats
• Reorganized settings to align with Cloudflare's recent dashboard changes
• Remove authentication option for Global API Keys (only allow API Tokens going forward)

Reorganization of settings moves settings to different categories and created sub-sections within cat