How I can trigger WAF rule based on operation system ?? so if i want to block linux for example how
How I can trigger WAF rule based on operation system ?? so if i want to block linux for example how I can trigger that
AShort version - you can't. If you're relying on the User Agent, those can easily be changed. (I'd also generally discourage blocking based on a users OS)
Show I can block based on user OS ??
ZLook one message up, Arch answered you.
DThis should be fixed now
SHi! I'm working on a discord bot that i'm running on workers. The same code executed locally works, but on a worker it gets a CANCELED outcome and I'm struggling to understand why. There's a not of helpful info attached to it, nor am I abel to find any documentation related to it.
What causes the outcome to be CANCELED?
What causes the outcome to be CANCELED?
KHello people, Where to share my open-source project related to workers? 
KAre you using Service Bindings?
K#what-i-built
KYayy thankss
SI have 2 KV bindings.
EDIT: just educated myself - no, not using any service bindings, but making a few API calls to discord in the lifetime of the request
EDIT: just educated myself - no, not using any service bindings, but making a few API calls to discord in the lifetime of the request
SI think I found out why - I added some waits to retry the rate limited calls, and that increases my CPU time way beyond the free limit of 10ms. (Not the ideal way to do it, I know. I'm exploring Workers so this is fun 
)
)
UA wait/setTimeout doesnt use CPU time, what does use CPU time is parsing the data from KV (or from the discord api) so the larger the value the more CPU time it uses. Local dev doesnt have any CPU limits thus it works fine no matter the size
UAnd KV doesnt really have rate limits so I highly doubt the calls to KV are ever being retried but the 1st call will succeed
SMy calls are to a third party api, some manipulation on the data and then create a thread and post multiple messages on that thread. But as you say, IO wait time would be different from CPU time, so I'm back to square one, on why the request gets cancelled before I return a response :/
Walso canceled is not due to cpu limits
Wcanceled means the client cancelled the request
Wso your Worker took too long to respond and the request was cancelled
Wif you're using interactions, they have a pretty fixed time to respond unless you defer
Wwaiting for these apis and things all add to that wall time limit imposed on you
Wi'd recommend deferring and responding when you can
Bcan I not add secrets in
Something like this:
.dev.varswrangler.tomlSomething like this:
K[vars]why?
KBecause that's what secrets are for. They can't be seen in the dashboard and aren't in files that you commit to VCS (like Wrangler.toml)
KIt's a shouldn't, not a can't - if you really want to you can but it isn't best practice.
Bso what is the alternative?
KThe message you replied to is in the conversation that explains it
K.dev.vars for local development, and secrets for production
W(
wrangler secret putenvironment variables are:
- variables that get set to different values based on the code's environment that is running on.
- plain text (and visible on the dashboard) or encrypted (and not visible on the dashboard).
- also known as "binding"s.
WranglerBis my understanding correct?
YAnyone here use Argo smart routing with workers? My workers throwing CORS error. When I open the url from browser.
When I change it to argo smart routing, it suddenly has captcha, probably that's the reason.
Any idea how to fix this?
Edit :
Turns out my domain is set to "under attack" a few years back.
When I change it to argo smart routing, it suddenly has captcha, probably that's the reason.
Any idea how to fix this?
Edit :
Turns out my domain is set to "under attack" a few years back.
Mare there any ways to avoid having to drill the
envconst secret = process.env.MY_SECRET at the top of a file and have it work like a node server, but surely there must be some other way to read from env without all this drillingMmaybe something with AsyncLocalStorage?
MI guess i could use esbuild --define to replace
process.env.X during the build, but probably not a good idea to do that with secrets. i wonder what other options there are
HALS is a good choice there
HThough as you noted, you need to make sure it isn’t called directly in the global scope
Mthanks @HardlyWorkin' or workin hard. do you know if there are any examples floating about of using ALS instead of "env drilling" for want of a better term
Ehas anyone been able to find an answer to this? find the
Would you like to report this error to Cloudflare? prompt really irritating
Ahi am new to clould flare and learning, i have deployed my first default worker and as soon as i deployed it it already had like 20 requests, without me doing anything, is that normal ? what are those requests ?
CBots scrape the SSL certificate logs and send requests to new hosts.
AThanks, they are sure fast starting scraping, like instant, hope they do not eat up too much of the free tier
CIt can help to disable the workers.dev subdomain for a bit when first creating the worker. Means the bots will get rejected when they first try it
Nfor storing profile pictures and other kinds of pictures (like product images uploaded), should I use R2 or Cloudflare Images (stored)?
Nwhich is more worth it?
AThanksss for the tip !
SHey everyone, MailChannels will be discontinuing our free API service as of June 30th. Details are in this knowledgebase article: https://support.mailchannels.com/hc/en-us/articles/26814255454093-End-of-Life-Notice-Cloudflare-Workers
I would post this in the community forum, but for some reason access was blocked.
I would post this in the community forum, but for some reason access was blocked.
Help Center
Since launching our free email sending API for Cloudflare Workers customers, we have been proud to provide a simple yet effective solution to deliver messages from Workers code with a minimum of se...
SStarting next week, you may notice a small fraction (1%) of your connections are rejected with an error message containing a link to the same announcement. Any messages that are accepted by the service will be delivered as usual and we will continue to provide support as usual until the final day of service.
JAh, good to hear. We've been advising people to avoid this partnership for quite some time, so it's good to get an official End of Life notice.
