[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.5

No permission to download
WAF is a weird one because Cloudflare's API tells us which settings are editable and which ones are not. It's why HTTP/2, Mirage and Polish settings probably can't be toggled for you (we make the interface adhere to what the API says can/can't be editable). The weird thing about the waf setting is that Cloudflare explicitly says that it is editable, even when it's not.

I checked the underlying code to make sure this still is the case, and this is what the API is returning for info for waf for a property I have on a free plan:

To me it looks like a bug on Cloudflare's side since they are specifically saying that settings is editable for the user, when in fact it's not. What I'm guessing is that when they rolled out WAF for free plans a few months ago, there was some confusion with how things are named compared to the API. I think the waf in the API is what used to be called WAF, but now it's called Managed rules, but since they can't easily change the name in the API, they left it as waf. And maybe some other engineer saw waf in the API and was like, "Oh, that's for all plans now... it should say it's editable for all."

If you are on a FREE plan, you are already receiving protection. Over the coming months, all our FREE zone plan users will also receive access to the Cloudflare WAF user interface in the dashboard and will be able to deploy and configure the new ruleset. This ruleset will provide mitigation rules for high profile vulnerabilities such as Shellshock and Log4J among others.

To access our broader set of WAF rulesets (Cloudflare Managed Rules, Cloudflare OWASP Core Ruleset and Cloudflare Leaked Credential Check Ruleset) along with advanced WAF features, customers will still have to upgrade to PRO or higher plans.

So ya, to me it looks like a bug in their API that (hopefully) will get itself sorted out. In the meantime, I don't think it's worth it to reload all the settings (multiple API calls) every time a setting is changed just to see if it really changed. You can reload the Settings page if you want, which would effectively reload all the settings from Cloudflare (that will always reflect the actual settings on your account regardless of what you tried to enable/disable before).

The issue with setting the switch after the successful API call is when you toggle something, everything on the page is set... so it wouldn't know which settings caused the error exactly (which is why it would need to simply reload all the settings).
when have a spare time, look at the HTTPS3 via UDP only. cloudflare said they released it, but not actually works.
if you manage to get it work, I can bring at least 1000 customers to XF.

the point is: government block websites via TCP
Honestly, I don't know enough about how certain government block Internet traffic to be of much help. But yes, HTTP/3 itself is built upon UDP rather than TCP. I have a click analytics system that makes a chart of the HTTP protocol that end users are using here: https://iolabs.io/analytics/sample/


Most users are using HTTP/2 (65%) and 32% are using HTTP/3, so I guess 32% of those users are using UDP as the underlying transport. For me personally, when I go to that sample page and check the HTTP protocol being used by my web browser, it is indeed HTTP/3:


So from the looks of it, Cloudflare is working fine/as expected with UDP (as long as you have HTTP/3 enabled for your zone under the network settings) since I'm pretty sure that HTTP/3 only works with UDP.

As far as how governments are blocking Internet traffic, I can't help much there... I mean what prevents them from just blocking all UDP traffic? That would effectively block HTTP/3, but not HTTP/2 (maybe that's what you are seeing?)...
The issue with setting the switch after the successful API call is when you toggle something, everything on the page is set... so it wouldn't know which settings caused the error exactly (which is why it would need to simply reload all the settings).
Okay, got it. Thanks for taking a look.
digitalpoint updated [DigitalPoint] Cloudflare with a new update entry:

Fix for issue with Cloudflare Worker unfurl proxy not getting it's route enabled

  • Support for new Cloudflare setting: Network -> HTTP/2 to Origin
  • Fixed an issue where the Cloudflare Worker for unfurl proxying would not have it's route enabled
Not particularly keen on putting out a followup release so quick, however there is an issue where the Cloudflare Worker for unfurl proxying would not have it's route enabled (and wouldn't work since there was no route).

If you've already enabled the unfurl proxy, all you need to do to enable the...

Read the rest of this update entry...
they can not block UDP. hardware not allows! that's most porn webs use cloud DNS, to bypass blocks
Uh what? No, that's wrong. You most definitely can block UDP traffic just like you can block TCP traffic. UDP isn't some magic protocol where network hardware is forced to route it if it doesn't want to. You can block it all or you can block specific port(s). Someone could block all UDP traffic except for port 53 (DNS) if they wanted.

I just double checked the router I use, and you definitely can choose to create firewall rules based on UDP and/or TCP (see the UDP drop-down on the Protocol line)?


So you could probably block HTTP/3 on your network simply by blocking UDP port 80 and 443.
it works like this:
client enters web, request sent to ip via tcp, if that found, it will return web if tcp is blocked,
request will check dns, which is top level hierarchy, dns send request via 53 port,
after finding web, reverse proxy returns another subdomain, which has mirrored data

to block this kind of UDP, must block all ip addresses of DNS service
Hello, i just installed this add-on and i try to create Access policies : when i click on th create button a warning/information message appears, then i click to the button in the overlay and i'm back to the page, there is no way to create a policy, what i am missing ?

On CF Dashboard i enable the ACCESS system. (Zero Trust now correct ?)
Any errors or anything in your XF server logs?

I just tested it by deleting the Access rules I have and then letting the add-on recreate them and it created them as expected. One possibility would be to go to Cloudflare Zero Trust -> Settings -> Authentication and make sure you have a Login method defined. The add-on is supposed to check that, but maybe Cloudflare changed how you check that? Not quite as easy to test on my end because deleting the login method causes some problems for existing users.
The only thing I can think of is if it's an API permission issue (although it's supposed to throw an exception you can see if that's the case). I've messed with various API permissions trying to replicate what you are seeing (no error and no action), but I haven't been able to do it. If I take away the Access permission (or make it read-only), it kicks back the expected permission error.

That being said, it probably wouldn't hurt to make sure your API permissions are set correctly. This is what you should have:


Make sure you have the right Account Resources, Zone Resources, check if you are IP filtering API calls as well as the TTL on the API token.

For me, I have Account Resources set to include All accounts and Zone Resources to be All Zones (then you can use the same API token across multiple sites).

Also make sure you have the Access: Apps and Policies set at the Account level, not the Zone level (it's a different API call then).
Oh ! Maybe it's too complicated for me or i don't understand well hw your add-on works.
I don't have any API in my CF, i have to create them all ? Where is the step by step notice for that ?


I used Global API keys in the add-on settings
Any chance you could switch to API token in your settings in XF Admin -> Options -> External service providers?

While it should in theory work with a Global API key, it's not recommended to use a Global API key (huge security issue because that API key can be used for any/all things in your Cloudflare account across all zones... could do some serious damage if that got stolen).

Maybe the Global API key doesn't work as expected with Access stuff? Worth a test anyway... and like I said, I'd really recommend NOT using Global API keys anyway.
I can of course, but i really don't know how to.
I'm on the right page in CF but i can' fill fields by myself to create a token.

NAME : XenForo
Authorisation : ??
Ressources : ??
IP Filter : I suppose i can leave blank here ?
TTL : ??
Top Bottom