Also just to clarify. We are hosting our api's on AWS. So the typical flow would be: Make request via CF domain -> Resolves to our Cloudfront CDN -> Trigger API on server. What we want to prevent is that an attacker could some how get ahold of our Cloudfront URL and bypass cloudflare. So we need a way to protect the API's for requests coming directly from the Cloudfront URL.

Hey all -- getting this error when trying to convert a arrayBuffer of the Response from downloading an image to Uint8Array

ts
const hexBuffer = await r.arrayBuffer()    
let bytes = new Uint8Array(hexBuffer as ArrayBuffer)

recursive use of an object detected which would lead to unsafe aliasing in rust

looks like a worker runtime thing. note that only one image is doing this. image is downloaded fine

I don't see it thrown from the runtime - that looks like it's thrown by wasm-bindgen

Unless it's just thrown by V8 itself, which would be odd

Yeah, that's wasm-bindgen

during wasm warm up or executing a method from the binding?

wasm-bindgen isn't something that is included in workerd

Are you using WASM in your Worker?

we do this but not seeing specific error because

(warn) Trace resource limit exceeded; subsequent logs not recorded.

ts
 await initialize(wasm).catch((e: Error) => {
    //We don't log the expected error
    if (!e.message.startsWith('Already initialized.')) console.error(e)
  })
  const ogImage = await svg2png(svg)

Is the image that fails larger than the rest?

smaller acutally

so naied it down to

svg2png

nvm

sometimes initialize thows that recursive exception

I'd have a global variable of

initialized

and only init inside an if check

ts
import esbuild from "esbuild-wasm";
import wasm from "../node_modules/esbuild-wasm/esbuild.wasm";

let initialised = false;
globalThis.performance = Date;

export default {
    async fetch(): Promise<Response> {
        if (!initialised) {
            await esbuild.initialize({
                wasmModule: wasm,
                worker: false,
            });
            initialised = true;
        }
        return new Response("Hello World");
    },
};

Example from

this helped stablize things

It sounds like what you want is something along the lines of this here: https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/#4-required-for-some-add-cloudflare-origin-ca-root-certificates With that you can edit the configuration on your server to validate the certificate from cloudflare before accepting the request and thus preventing anyone from sending request not though cloudflare. For example in Nginx you would add something like this to the server configuration:

ssl_client_certificate /etc/ssl/certs/cloudflare-origin.pem;
ssl_verify_client on;

About all of this there is also this excellent blog post: https://blog.jfx.ac/securing-nginx-origin-with-cloudflare.html

some progress made.

ts
let ogImage = null
  try {
    if (!initialized) {
      await initialize(wasm).catch((e: Error) => {
        //We don't log the expected error
        console.debug("Couldn't initialize wasm", e)
        if (!e.message.startsWith('Already initialized.')) console.error(e)
      })
    }
    console.debug('initialized wasm')
    initialized = true
    ogImage = await svg2png(svg)
  } catch (e) {
    console.error('Failed to convert svg to png')
    console.error(e)
    return ''
  }

in some instances however now we are getting

✘ [ERROR]   Error: Promise will never complete.

Bleh, might not work with svg2png then.

works sometimes tho 😦

cf images doesn't do svg to png iirc?

I experience some problems with cron triggers. The worker is unable to make a request to a non standard http port to a external service on the same domain (no-proxy DNS). Getting 404 if the worker is triggered with a cron event. It do work though if I trigger the same worker with a fetch request instead.

I then created a port proxy worker that proxies between the non standard http port and 443 in the same zone. As a result the reverse is true: the cron trigger works but not the worker triggered by an fetch event! I assume the fetch worker can't communicate with the port proxy directly because it's in the same zone. But it seems the cron triggered worker i able.

So it seems like the cron triggered worker is running in another zone

trying something new. so, workerd won't support something like this?

ts
return WebAssembly.instantiate(
    wasmModule,
    imports
  )

(this works in wrangler2 but not deployed)

[object WebAssembly.Instance] { memory: {} }

(error) RuntimeError: unreachable

in other words, exports attached to mem locally but not on CF 😦