Users with access to your account are able to download your scripts, they are not end-to-end encrypt
Users with access to your account are able to download your scripts, they are not end-to-end encrypted in that sense
Thow? where? I don't see anywhere in the UI to download the built code of a specific version of a deployment
TOh I just found the "edit code" button in the top right. Had not seen that before.
TI assume there's no way to disable that? Considering the code visible there (in most cases) is the esbuild-bundled code, and editing it would circumvent CI and other tooling and workflows, it's kind of useless anyway. Removing the ability to access it would be helpful to me from a security standpoint. (added a note in #workers-feature-suggestions)
HEven if you were able to prevent downloads, that wouldn’t stop someone from account access from disabling your Worker, or replacing it with a script of their own
Tthat's ok - my main concern is accessing the code. But discouraging/stopping someone from using that edit interface to change and redeploy the worker is also a nice bonus
HAlso, iirc there was a point where Workers deployed via Wrangler weren’t editable in the dash, but iirc they rolled that back because people wanted to be able to use it anyway
HI know I’ve sometimes used QuickEdit to make some fast changes on the go
TI could imagine a simple setting to just disable it
Twhether in wrangler.toml, or a flag during deploy or both
AFundamentally, you would point your domain to Cloudflare usung DNS or Nameservers, after adding the domain to your Cloudflare account and then configure your Worker to handle traffic for that domain using Worker Routes. Keep in mind once you change the DNS, if you only want Cloudflare to handle redirects, and still serve content that currently exists, you’ll need to set that up to.
Sdoes cloudlfare worker request to http2 ? like APNs
Hhi
Hi am very confused about preview captcha not showing :blob_sweat: at worker proxy
BFor ESBuild bundling, is there a way to turn on
--minify-syntax? It seems that dead code like if (false) { ... } do not get eliminated.BAh, seems like
wrangler deploy's --minify turns on all minify features of ESBuild (so whitespace + identifiers + syntax), and it's off by default. Is this safe?Hthank ill try it
Hdo you have example
BMy question wasn't related to yours, in case that's why you are asking.
BBut for minifying, you can set
minify = true in wrangler.toml--minify.
DIs there a simple way to only allow my Cron job to have 1 instance running at a time?
Dthat seems kinda heavy handed to add a DO just for a lock, no?
DI'm using Hyperdrive, I guess I could do a lock somehow with the database?
CI saw that too, hopefully we get a retroactive status page if nothing else. Was it a worker using static assets?
CSame for me. I bet the static asset handling part is a worker on its own which had an issue for a bit, or at least it's def related to that in some way. All my other workers were fine
Chey there, i'm facing this weird behaviour when using lower case, for navigation word the pipeline fails finding the module, still both versions works on local.
import Navigation from "~/components/Navigation"; OK
import Navigation from "~/components/navigation"; FAIL
import Footer from "~/components/footer"; OK
import Navigation from "~/components/Navigation"; OK
import Navigation from "~/components/navigation"; FAIL
import Footer from "~/components/footer"; OK
Cis
navigation a reserved word or has a distinct treatment in the workers builing pipeline context?
CIf you're devving on Windows, it's going to be case insensitive until it hits the linux-based very much case sensitive build ci/cd env
Cnah, it mac .. weird things
CI think mac is case insensitive too by default? I mean, what's the actual file name you're trying to import?
Cso i'm having
then using
import Navigation from "~/components/landing/navigation";
all good on local, fails on CF side.
Why i'm saying is very weird, is because if i rename the directory from
/landing/navigation/index.tsx exporting export default ...then using
import Navigation from "~/components/landing/navigation";
all good on local, fails on CF side.
Why i'm saying is very weird, is because if i rename the directory from
navigation to nav and update the inport too. CF works also
Chuh, so very weird ..
navigation, header directory names not working, but nav doesCwell, i think i was messing with the tsconfig. looking to another cf worker example and this seems to work now. ty @Chaika
Tthere are weird case issues with git and mac vs linux. On many projects I've tried to name everything in
As you have just discovered, it will bite you when you try to change the case only on something.
kebab-case to avoid it, but it is a bit of a pain when dealing with frontend PascalCase components.As you have just discovered, it will bite you when you try to change the case only on something.
JAny recommended way to cache Google API Oauth Tokens on a free workers plan without using a db or cloud storage solution?
Found this when searching but not sure if its recommended in 2024
Found this when searching but not sure if its recommended in 2024
Iwithout using a db or cloud storage solutionThe answer in the screenshot is really the only way to do so. Keep in mind that it's only going to be cached in the colo the Worker is running in, so if another Worker in another colo is triggered then it won't see the cached value.
WAny reason to not use a db like d1?
I^ or KV
JAh given my Google oauth token has a TTL of approx 3600s, i would attach something like this to my fetch request and it should ~roughly reduce some request load given a worker in the same data center is executed?
cf: {
// Always cache this fetch regardless of content type
// for a max of 5 seconds before revalidating the resource
cacheTtl: 3400,
},
This is for a project operating at very small scale, think a request load of ~ <= 125/month on average hitting this api endpoint and thats an estimate on the high side -- i don't want to inject the complexity of a full blown db in this case
I would probably be fine with just refreshing the google oauth tokens as well on every request but don't mind understanding if there are some optimizations Cloudflare provides for cases like this
cf: {
// Always cache this fetch regardless of content type
// for a max of 5 seconds before revalidating the resource
cacheTtl: 3400,
},
This is for a project operating at very small scale, think a request load of ~ <= 125/month on average hitting this api endpoint and thats an estimate on the high side -- i don't want to inject the complexity of a full blown db in this case
I would probably be fine with just refreshing the google oauth tokens as well on every request but don't mind understanding if there are some optimizations Cloudflare provides for cases like this
ISo two main points based on your requirements:
- This is an OK solution if you don't want to involve a DB.
- At that low load then it probably won't do anything anyway, though, because 3400 is "3400 seconds" which is around an hour. If you have less than 125 req/month, then unless more than 1 per hour comes in (1 per hour and in the same colo, and Cloudflare has more than 350 so that's quite unlikely) then it won't be cached.
- At that low load then you really don't need to worry about Google OAuth's servers, they can easily handle that load and I expect they're fairly quick (unsure?) so the actual OAuth refresh is likely less than the thing you're using the token for anyway.
LI want to ask if there was any issue with the assets binded worker around 20:00 UTC on December 17th. There was a moment when my website was inaccessible, but there were no actual losses. I am aware that we are still in the testing phase, but curiosity makes me wonder what happened behind the scenes.:MeowHeartCloudflare:
SHi! I am new to workers. Currently I build a worker to fetch an API and compare with the result fetched 5 minutes ago (with cron).
I am using KV to store that API result so that I can use it for comparison for the next call. Is there better way to store the result for use a? Is using KV/D1 a must?
One of the concern is KV write/day will be
I am using KV to store that API result so that I can use it for comparison for the next call. Is there better way to store the result for use a? Is using KV/D1 a must?
One of the concern is KV write/day will be
24*60/5=288, and this is not really scaleable if the free quota only has 1000 write/day. getting 4 API will exceed the free quota... and I probably need more only in testing stage.SAnother question: may I know the reason why even when I am using dashboard to create a new worker (from Hello World template), the logging will automatically turn off when I publish a new version, even if I am not using wrangler in the whole project? Am I doing anything wrong?
Ti know this is a reach but does cloudflare workers have any plans to support docker containers like google cloud run?
Ti would love to take advantage of a serverless http3 solution
Ahttps://blog.cloudflare.com/container-platform-preview/ it’s coming next year, but the details are largely TBC in terms of what you can run & how
The Cloudflare Blog
We’ve been working on something new — a platform for running containers across Cloudflare’s network. We already use it in production, for AI inference and more. Today we want to share an early look at how it’s built, why we built it, and how we use it ourselves.
Tabsolute banger
