well lets say one worker rpc invokes another worker, is it still considered a request?
well lets say one worker rpc invokes another worker, is it still considered a request?
Bit is a request for DO's but not sure about workers
ADoes the workers runtime perform JIT optimisations? It says V8 in the documentation but im not sure Turbofan is enabled
PHey, do you know if CF filters Authorization header to workers?
PI have a code that used to work but now it's broken
RI doubt it, that would break many use cases.
PPIs this a wrong way to read an authorization header?
Rtry
request.headers.get('Authorization')PI don't regularly write JS so I am not sure why is that [] is not equal to that but hopefully it works.
PHmm, I get a different error now
PThanks for the help
RIs there a limit to the number of routes that can be configured in wrangler.toml?
RThanks, more than enough for my use case then.
RAnyone else seeing 524s from a bunch of worker API endpoints?
Cno, everything seems ok to me
Csometimes the dashboard decides it wants a break for a bit, possible it was only for a second
PWhy regex is weird in JS?
RYeah looks like a minor blip, everything is working again now.
SIs it possible to restrict bindings? Say I want an auth service worker that I want to make sure is the only worker that can access the auth R1 database. Is there any way to prevent another worker from accessing said database eg from being bound? I know we can restrict a worker to be only able to be communicated to by other workers.
Cno, but why? You can only make bindings in the dash/via wrangler, and if someone has your dash login/credentials they could just remove that restriction
SCan't you do it via wrangler.toml?
Cmake a binding? Yea, that'd be via wrangler, they'd need your credentials for that, with such they could just bypass that limitation
SAlso in theory someone could extract a bearer token and use the same token to access another D1 DB.
SThe file exists in the repo no? So it means having tighter security controls on the auth service DB for instance wouldn't be of value because say an open source component that uses that service could be compromised and access the auth DB.
Cif they have your token, you need D1 scope to even publish a Worker afaik, so it could just be used to access them at all
.With cf workers, you can use like cloudflare’s own database, does this cost? Is there info on costs?
CCI mean you can't scope tokens even to specific workers, so they could simply override your auth worker anyway
SGuess that could be a place for future improvement, more granular access management for workers and resources in general
SI'm not hosting any high risk data but it'd be an inhibitor to doing such a thing if I were
Cthat's for sure
CI wouldn't start with restricting what workers can bind to things though
SIt'd fail PCI compliance this way though unfortunately
SSimple role based access would be plenty if you could openly configure what those roles could do
Cyea really need worker/pages project granularity
SAlso vital for large scale projects for user permissions too
SWorkers could just piggyback on the same rbac
Chopefully r2 having bucket scoped tokens is just a start of getting those more granular resource-level scopes
SA terrifying but necessary thought haha
SAnd also probably against CF TOS haha
Cthen you'd need workers paid like x100 over
SFor an auth service it wouldn't need to be hit hard
Cnah making extra accounts isn't, I have like 5, just what leo said, can't make them to purposefully evade limits
SI just want to segregate critical data like user PII
SI remember when you couldn't even join cf accounts, it wasn't that long ago
Cused to have no roles for free accts except superadmin
Cgot a lot better rbac now
SIt seemed kinda duct taped together
SEncrypting is useless here if you can get the decryption key
