ah right, I believe there should already be an `CF-Worker` header that your origin/server receives
ah right, I believe there should already be an
CF-Worker header that your origin/server receives
Pwhich has the same value as the upstream_zone one
Sthat would only appear if my server side (worker) is requesting the API tho right?
in my case the browser also requests that api endpoint. maybe mTLS is actually what im looking for?
in my case the browser also requests that api endpoint. maybe mTLS is actually what im looking for?
Pyep it would only appear if the request comes for a worker, which could be yours or someone else's
SOkay good to know i will definitely need this for another project. But in this case i guess its fine to just allow access to it
1Will there ever be an option for higher memory Workers?
I know CF is always upgrading their servers but do those performance upgrades make their way to V8 isolates in a meaningful way? Does 1ms of CPU time now do markedly more work now than 1ms of CPU time 3 years ago?
I know CF is always upgrading their servers but do those performance upgrades make their way to V8 isolates in a meaningful way? Does 1ms of CPU time now do markedly more work now than 1ms of CPU time 3 years ago?
1Just some general thoughts I was having. I have reformatted to correctly match my thinking of those being two thoughts separate to each other
AI’d say it’s more likely the upcoming container product will allow you to have more / tune memory rather than Workers raising memory, but no info yet on whether that will be possible afaik
SJust double checking. It has been mentioned that worker assets are cached even tho its not shown. Means even images having
public, max-age=0, must-revalidate is fine right?Si really cant get Build Environment variables to work when i put them in my wrangler config. i usually set them in the dashboard but id like to have some default ones in there like node_version. i tried
vars and env production but neither will show up in the build details
AHey, I am using cloudflare workers and I noticed my workers are getting requests for a bunch of routes like
I do use the WAF managed rules: Cloudflare Managed Ruleset, Cloudflare OWASP Core Ruleset, and
Cloudflare Leaked credentials Check
Do you know how I can make sure cloudflare blocks these suspicious requests?
/js/.env, /aws.yml, /config/settings.prod, etc.I do use the WAF managed rules: Cloudflare Managed Ruleset, Cloudflare OWASP Core Ruleset, and
Cloudflare Leaked credentials Check
Do you know how I can make sure cloudflare blocks these suspicious requests?
Pevery public site will get random crawlers/bots that will hit all types of endpoints/paths to see if they can dig something up
Psome of the managed ruleset WAF rules cover the very common ones, but not necessarily all possibilities out there
AI would expect the CF WAF to block .env requests 
AWe have enterprise plan, and we use our own domain
A
AThat's why I'm wondering what I am missing
Acause /config/settings.prod why not let it slip, but
**/.env should be blocked all the timeAActually, the core ruleset is not enabled? It's just logging
AActually the rules are blocking a ton of things 
AI'm using Tinybase to syncronize data using a Durable Object. I'm also persisting the data to the Durable Object storage. I want the data to be able to live longer than the Durable Object. Is there a way to persist the Durable Object storage to D1?
AAh. I'm glad it was a misunderstanding on my part.
KHi, how do I set this up for queues?
https://developers.cloudflare.com/workers/wrangler/configuration/#non-inheritable-keys
https://developers.cloudflare.com/workers/wrangler/configuration/#non-inheritable-keys
Cloudflare Docs
Use a configuration file to customize the development and deployment setup for your Worker project and other Developer Platform products.
FHi all, is there a way that I can download my Pages source files?
K[[env.production.queues.producers]]...interesting it has to be defined this way
Chow private are pages projects...i just got a request for /js/twint_ch.js on my page.dev domain on my console logs....but that file doesn't exist and nobody should have access to anything i am doing that would request that...idea?
AThe internet is littered with bots and your pages.dev domain is public, and things like DNS are too, so bots end up finding it
Cthat's scary..how do they find it, is cloudflare publicizing it?
Cor is there a mouse in the house and cloudflare dev ops need to wake up
Swelcome to the internet.. its normal
AThis is just how the internet works, anything public can be found and bots are everywhere - it’s nothing to worry about though, assuming what you have there isn’t private data or anything
SWhat im more confused about now is how i pass the ctx.waitUntil to a function
i ran into the classic
do i really need apply/call in that situtation?
i ran into the classic
TypeError: Illegal invocation: function called with incorrect this reference first. now when i pass down the entire platform into the function waitUntil ends up undefined (its available where im trying to pass it to the function)do i really need apply/call in that situtation?
CEvery pages.dev gets a certificate, certificates are all logged as part of Certificate Transparency (CT) Logs the second they are issued, bots listen to CT Logs
Cthat seems to be a security risk the platform in users...why is that public?
IIt's just how the internet works. It's not specific to Cloudflare, every platform works this way.
IAny time a certificate is issued, anywhere (that is trusted by browsers), it's logged publicly.
Copposite, Certificates Issuance are public to increase security. So no Certificate Authority can issue Certificates without it being known
I
Cokay so...would it not be smarter to set these tempory pages.dev things via: page.dev/subfolder instead a a subdomain?
HSome projects deployed to Pages may expect a (sub)domain to themselves
IThe issue with this is that they have no way to know what you have on the production domain.
IIf you put it at
/foo then what if I have a file/folder in prod that's called /foo?IIt would overwrite it.
CNo, for security again, as pages.dev uses subdomains and is part of the public suffix list, browsers treat each subdomain as its own website, separated in terms of cookies, cors, etc
CIf you were using subpaths, browsers would assume each pages website are part of the same security context/get around some limits of CORS, allow access to cookies, etc
Coh, even if you mean just for preview URLs it'd still be more way messy for the reasons Isaac said
Cthis is all true, but also true is that these bots are a problem. perhaps on this domain cloudflare could think of a way to be more pro-active against the bots and honey pot them to immediately get them on a block list. Or maybe they are and this is just one that got through
IEven for preview URLs this would apply ^
IImagine if you set a cookie on the preview path to log a user in, and then it applies on the prod path too
CBots just aren't really an issue, and it's very difficult to block only the bad ones without blocking intentional ones
IYou can always put Access in front if you're worried about security.
