CORS Issue
So I setup a few endpoints and they work great. Ironically the simplest of things evades me and that's my NodeJS App. I deployed a cpu pod and connected to storage as I needed deployed the container and ouef.
https://t1vks417dcde8m-3000.proxy.runpod.net/
{"level":50,"time":1752575170368,"pid":35,"hostname":"8833baa5d40d","locals":{"sessionId":"4f56ab53468849baae365477000dce885cda2bd9c919f740324af98cb1c80bef","isAdmin":false},"url":"https://100.65.14.188:60285/","params":%7B%7D,"request":%7B%7D,"message":"Internal Error","error":{},"errorId":"39a1a186-e93e-4cff-938b-6d730cff0d7c","status":500,"stack":"Error: CORS error: Incorrect 'Access-Control-Allow-Origin' header is present on the requested resource\n at universal_fetch (file:///app/build/server/index.js:2564:17)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}
So the pod, proxy, firewall, cloudflare mix is screwing with Origin Headers.
I deployed it to another provider to make sure it's not a code issue and it works flawlessly, ironically they also proxy the container port to 80. And they also use cloudflare.
https://krisv99-lustychat.sliplane.app/
Would love if this could be fixed. As the app needs access to the endpoints storage. Which even via s3 doesn't seem to be available outside your web of confusion.
LustyVerse
Welcome to the LustyVerse!
3 Replies
Can you explain this a little bit more? I want to understand so I can open a ticket with our engineering team without sending you through support and doing the back and forward over email @Morganja
Your issue makes sense but do you know where in the process you're losing the header?
So I've got my local_origin set to:
https://t1vks417dcde8m-3000.proxy.runpod.net/
So auth is:
https://t1vks417dcde8m-3000.proxy.runpod.net/login/callback
So:
Docker responds on 0.0.0.0:3000 -> Runpod Proxy which redirects 3000 -> 443
Which then goes to an Internal Load balancer which passes it to cloudflare which passes the requests to the interwebs.
So at some point the header changes to: https://100.65.14.188:60285/ But I've also tried setting that has Origin and it still fails. And because of that my hooks server goes mental.
My reference case: https://krisv99-lustychat.sliplane.app/ Does things a little different they use docker pf so 0.0.0.0:3000 to dockerip:80 and use cloudflare SSL to resolve https://krisv99-lustychat.sliplane.app And simply setting my Origin to https://krisv99-lustychat.sliplane.app/ works flawlessly. So the issue lays with https://100.65.14.188:60285/ layer of the cake... but I'm not sure... how why this is even being seen.... What's more frustrating is https://100.65.14.188:60285/ seems to be session based of some sort? as it doesn't respond with anything.
So at some point the header changes to: https://100.65.14.188:60285/ But I've also tried setting that has Origin and it still fails. And because of that my hooks server goes mental.
My reference case: https://krisv99-lustychat.sliplane.app/ Does things a little different they use docker pf so 0.0.0.0:3000 to dockerip:80 and use cloudflare SSL to resolve https://krisv99-lustychat.sliplane.app And simply setting my Origin to https://krisv99-lustychat.sliplane.app/ works flawlessly. So the issue lays with https://100.65.14.188:60285/ layer of the cake... but I'm not sure... how why this is even being seen.... What's more frustrating is https://100.65.14.188:60285/ seems to be session based of some sort? as it doesn't respond with anything.
LustyVerse
Welcome to the LustyVerse!
LustyVerse
Welcome to the LustyVerse!
@Dj However I'm also now in the middle of rewriting my Image Gen worker to use BB for image storage so I can remote the app now and leave RP just for compute ... However I intended to take advantage of the whole shared /workspace mount system (despite not being able to mount more than one to a docker) was faster ... ish...