https://discord.cloudflare.com logo
Join Discord
Powered by
# workers-discussions
  • d
    the only different thing we do for the frontend, is support using a refresh token. The JWT is encrypted as a JWE, to avoid the frontend team from getting curious and wanting to parse stuff they shouldn't parse lol.
  • e
    Nice! This would be awesome to share in #783765338692386886 🙂
  • a
    I'm trying to make a worker which (among other things) receives a file and send it to R2. I'm making the call to the worker with a multipart/form-data body and I'm receiving it well in the worker, but the key which contains the file blob is not there. I don't know if I'm doing something wrong or it's a bug of any kind... I'm going a little crazy, anyone has a little help of me? T.T
  • j
    Quick and easy question: I currently use const config = { domain: "example.com", } in a worker to define the domain. How do I define the domain to whatever domain the worker is working on?
  • n
    I'm using the Typescript template here: https://github.com/cloudflare/workers-sdk/blob/main/templates/worker-typescript/src/index.test.ts When I use 
    npm test
    none of my KV bindings, secrets, etc are available. They are however available when running using 
    wrangler dev
    . What am I doing wrong?
  • k
    You could probably just read the request URL
  • k
    Copy code
    js
export default {
  async fetch(req) {
    const url = new URL(req.url);
    const { hostname } = url;
  }
}
  • s
    Moved it there. Thank you! 🙂
  • j
    Awesome, thank you!
  • j
    I use the Welcome Bar app, but when I enable the worker route, it disappears. How to avoid?
  • d
    @sathoro it's even worse.. Supabase limits on CF-Connecting-IP. https://developers.cloudflare.com/fundamentals/get-started/reference/http-request-headers/#cf-connecting-ip-in-worker-subrequests

    https://cdn.discordapp.com/attachments/779390076219686943/1105494429961289819/image.pngâ–¾

  • s
    Supabase uses CF so it would be the Worker's IP address right?
  • k
    It'd be a shared IP that all Workers 'appear' as
  • k
    All cross-zone requests are 
    2a06:98c0:3600::103
    , but that's not the 'real' IP that the request comes from - just what appears in 
    CF-Connecting-IP
  • k
    so it'll be ratelimited, uh, very heavily
  • d
    yeah
  • d
    yeeeeeep, emailing them back now to explain it
  • d
    hmm, what would they need to change on their side to avoid the rate limiting? (I'm trying to give them as much of the solution as possible. 😛 )
  • k
    Ratelimiting Workers means going off the 
    CF-Worker
    header, which is only present on requests from Workers.
  • k
    so they'd probably maintain 
    CF-Connecting-IP
    generally but 
    CF-Worker
    would take precedence
  • d
    shouldn't it be cf.worker.upstream_zone?
  • k
    If they have the Enterprise + add-on for doing it in Cloudflare, yeah.
  • k
    Otherwise, it's a normal request header they'll get on their origin.
  • k
    Depends if they're using CF for ratelimiting or not.
  • u
    Even enterprise cant select worker upstream zone in the characteristics selector from what I see
  • k
    Works for me
  • k
    Well, with Edit Expression
  • k
    I have 0 out of 0 rules so I can't actually use it, it just doesn't throw an error
  • u
    you cant edit expression for the characteristics
  • d
    > When configuring firewall rules, do not match on this header. Firewall rules are applied before Cloudflare adds the CF-Worker header. Instead, use the cf.worker.upstream_zone dynamic field, which contains the same value and exists for the same purpose. But this confuses me, I thought 
    CF-Worker
    wasn't going to work for rate limiting?
1...244824492450...2509Latest