Hoffi
Well-known member
Yes. I had not the priviledge in the API, so it did not work to turn on, but the switch was still in on position.Are you talking about on the Settings page?
Maybe set the switch after succesfull API call?
Yes. I had not the priviledge in the API, so it did not work to turn on, but the switch was still in on position.Are you talking about on the Settings page?
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.
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/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
Okay, got it. Thanks for taking a look.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).
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).
- 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
If you've already enabled the unfurl proxy, all you need to do to enable the...
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.they can not block UDP. hardware not allows! that's most porn webs use cloud DNS, to bypass blocks
- Removed stray variable in a tooltip
- Fixed issue where setting values considered "good" when disabled would show the opposite value for their setting (things like
Development Mode
andRocket Loader
which are considered "good" when disabled)
Ya, any identity provider should work (I don't personally have experience with the one-time pin option, but it shouldn't matter).
All accounts
and Zone Resources to be All Zones
(then you can use the same API token across multiple sites).Access: Apps and Policies
set at the Account
level, not the Zone level (it's a different API call then).We use essential cookies to make this site work, and optional cookies to enhance your experience.