I'm trying to fine-tune my cache settings with Cloudflare for better performance. Because AbleCommerce is a dynamic system, you have to be careful what you cached, otherwise, someone else's information could be displayed to the wrong person.

That being said, what areas in AbleCommerce should never be cached or subject to being cashed, please see below.

/Checkout
/Admin
/Login

Have I missed anything?

Thanks

Thank you for your prompt reply; I forgot about that one. I had an issue with the home page, the default page, and I had to put it under no cache.

My issue was if you force the home page to be cached, the upper right admin link is missing when an admin logs in. You would have to go to a different page for it to reappear. I wonder if that had anything to do with members.

Either way, I will continue testing and get back to you.

I no longer see an issue with the product pages in the event of a change in pricing; it will refresh properly.

Either way, any change to any static page would require a purge at Cloudflare. Eventually, Cloudflare will override all cache instructions from the origin server. Tweaking one day at a time.

I appreciate your support.

Edited by user Monday, July 3, 2023 9:03:14 AM(UTC)  | Reason: Not specified

I've set up Cloudflare on a few AC9 stores now, so I figured I'd post the full list of what I go through. I won't go into exact settings for every item, but if you work through this you shouldn't miss anything.

First, about the missing admin link Ray ran into earlier in this thread: that's what happens when you cache HTML pages in AbleCommerce. Cloudflare keeps a copy of the page the way one person saw it and hands that copy to everyone. The admin link is just the one you notice. The mini basket, account links, group pricing and the hidden tokens on the login/review/contact forms all get mixed up the same way, you just don't see it right away.

So my rule is: cache the static stuff, don't cache the pages. Every visitor (even a guest) gets a cookie and a basket on the server the moment they land, so pretty much every page is personal. Cloudflare's APO full-page caching is WordPress only, so that's out too.

Never cache these

• /Admin
  
• /Checkout
  
• /Basket
  
• /Members
  
• /Login, plus logout, register and password reset
  
• /api/ (webhooks and AJAX calls live here)
  
• Captcha.ashx
  
• Download.ashx and DownloadDigitalGood.ashx
  
• Reorder.ashx and any of the export handlers
  
• Payment gateway return/callback/IPN URLs
  
• Any plugin routes that receive calls from outside
  
• POST requests in general
  

Make the bypass rule your last cache rule so nothing above it can override it.

Safe to cache

• CSS, JS, fonts, icons, theme images
  
• Product images under /Assets
  
• GetImage.ashx, as long as you keep the query string in the cache key
  

I set the edge TTL in days, not months. If someone re-uploads a product image with the same filename, the old one hangs around until it expires or you purge it. Keep the browser TTL shorter than the edge TTL, turn on Tiered Cache (it's free), and have IIS send proper Cache-Control headers on static files.

If you really want the home/category/product pages cached, it can be done, but it needs code changes. The per-user bits (mini basket, account links, form tokens) have to come out of the page and get loaded with AJAX afterwards. Then you bypass for logged-in users, keep the TTL short and purge when prices or stock change. If you use group pricing I wouldn't bother.

Before you start
Make a list of:

• Every DNS record, especially the email ones (MX, SPF, DKIM, DMARC) and any verification TXT records
  
• Everything that calls into the store from outside: gateways, IPNs, POS/inventory webhooks, tax, shipping, uptime monitors
  
• Any webhook that checks its signature against the store URL (Square does this)
  
• Admin jobs that run longer than 100 seconds
  
• Where the store is hosted (Azure App Service, IIS on a VM, shared) and which Cloudflare plan you're on
  

DNS and SSL

• Only proxy www and the bare domain. Leave email and verification records grey cloud (DNS only). A proxied DKIM record will quietly wreck your email deliverability.
  
• Full (strict) only. Flexible gives you redirect loops with AC.
  
• Put a real cert on the origin. A Cloudflare Origin CA cert is the easiest. Azure's free managed certs can fail to renew once the domain is behind Cloudflare.
  
• Turn on Always Use HTTPS and Automatic HTTPS Rewrites, and set the minimum TLS to 1.2.
  
• Do HSTS and your http/www redirects in one place, either IIS or Cloudflare, not both.
  
• Don't touch the store URL in AbleCommerce.
  

Speed settings
Brotli, HTTP/3 and Early Hints on. Polish/Mirage on Pro are fine, just check how the product images look afterwards.
Rocket Loader off. It breaks jQuery, form validation and payment scripts. Email Obfuscation off too.

Security

• Turn on the managed WAF rules, then watch the firewall events for a week or so. Checkout and the admin HTML editors sometimes trip them.
  
• Leave Bot Fight Mode off. You can't exempt any path from it, and it will block your webhooks. On Pro and up, use Super Bot Fight Mode and skip it for the webhook paths.
  
• For webhooks and gateway callbacks, add a WAF skip rule, turn off Browser Integrity Check and don't put any challenge in front of them.
  
• Rate limit POSTs to checkout and login per IP. This helps a lot with card testing.
  
• Lock /Admin down by IP or put Cloudflare Access in front of it.
  
• Under Attack mode blocks webhooks too, so keep that in mind if you ever turn it on.
  

Lock down the origin
If people can still hit the server directly, Cloudflare isn't protecting much. Only allow web traffic from Cloudflare's IP ranges (App Service Access Restrictions, an NSG or the Windows Firewall). Keep deploy/RDP access on their own rules. Before you lock it, change anything that calls the server's own hostname (monitors, webhooks) to use the real domain.

AbleCommerce gotchas

• Customer IPs. Without a fix, every order, user record, fraud check and gateway call gets a Cloudflare IP. You restore the real one from the CF-Connecting-IP header, either with IIS URL Rewrite or in code.
  
• Cloudflare times out at 100 seconds (error 524), so long imports, exports and syncs will fail.
  
• 100 MB upload limit on Free and Pro.
  
• Random logouts usually aren't Cloudflare. You need a fixed machineKey, and sticky sessions if you run in-proc session on more than one instance.
  
• Don't let anything redirect a webhook POST. The body gets dropped and the signature check fails.
  
• Server errors will show Cloudflare's error page unless you set up custom error pages (Pro).
  
• Purge after deploys, or use versioned file URLs.
  

Cutover
Export the zone first. Have every rule built before you switch nameservers, test the origin cert, drop your TTLs a day ahead, then switch when it's quiet. I lock the origin down last, once everything checks out.

Then test:

• cf-cache-status shows HIT on static files and BYPASS/DYNAMIC on pages
  
• Two browsers at once (one admin, one guest with stuff in the basket): admin link, account links and mini basket are right in both
  
• Login, register, reviews and the contact form all submit
  
• A test order goes through on every payment method
  
• Webhooks and IPNs still arrive
  
• Orders show the real customer IP
  
• Email still passes SPF/DKIM/DMARC
  
• Admin saves and imports work
  
• No redirect loops
  
• You can't reach the server directly anymore
  

After that it's mostly upkeep: check the firewall events now and then, purge after image changes, keep an eye on the origin cert expiry and retest checkout whenever you change something in Cloudflare or update a plugin.

If anyone wants a hand with this, I do this kind of work, including the code changes if you want page caching done safely. Feel free to PM me, email [email protected] or call 206.325.5383 x0.