Preview fails to load with status 500 when using proxy

[andlil]

Checklist

• [ x] I have searched budibase discussions and github issues to check if my issue already exists

Hosting

• Self
  • Method: docker
  • Budibase Version: 3.4.16

Describe the bug
Preview in design keeps loading

When looking at source/network I see the following error
"{
"message": "Unable to retrieve app DB - no app ID.",
"status": 500
}"

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

App Export
If possible - please attach an export of your budibase application for debugging/reproduction purposes.

Desktop (please complete the following information):

• OS: MacOS, Windows 11
• Browser Chrome, Edge, Safari
• Version

Additional context
Add any other context about the problem here.

[linear]

BUDI-9073 Preview in design keeps loading

[andlil]

If I access my selhosted Budibase direct through http://my.internal.ip:10000 everything works just fine.

If I access through domain name via traefik proxy (https://my.domain.com) the preview in design fails to load with a 500-error, specifically the page https://my.domain.com/app/preview.

Below is the log from budibase

bbapps | {"level":"ERROR","timestamp":"2025-02-22T07:49:12.901Z","service":"@budibase/server","err":{"type":"Error","message":"Unable to retrieve app DB - no app ID.","stack":"Error: Unable to retrieve app DB - no app ID.\n at Object.aS (/app/dist/index.js:7:15717)\n at q1t (/app/dist/index.js:998:3521)\n at q1t (/app/node_modules/dd-trace/packages/datadog-instrumentations/src/koa.js:88:57)\n at q1t (/app/node_modules/dd-trace/packages/datadog-shimmer/src/shimmer.js:31:21)\n at q1t (/app/node_modules/dd-trace/packages/datadog-shimmer/src/shimmer.js:31:21)\n at dispatch (/app/node_modules/koa-compose/index.js:42:32)\n at /app/dist/index.js:478:50199\n at /app/dist/index.js:885:26314\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async BWr (/app/dist/index.js:619:36632)\n at async /app/node_modules/koa-compress/lib/index.js:38:5\n at async Ijr (/app/dist/index.js:484:4655)\n at async /app/node_modules/koa-mount/index.js:52:26\n at async userAgent (/app/node_modules/koa-useragent/dist/index.js:12:5)\n at async Ojr (/app/dist/index.js:484:5710)\n at async oat (/app/dist/index.js:484:8873)"},"pid":29,"tenantId":"default","correlationId":"a1ea97f0-6c45-4472-9a71-e264be97b677","msg":"Got 400 response code"}

bbproxy | 192.168.4.200 - - [22/Feb/2025:07:49:12 +0000] "GET /app/preview HTTP/1.1" 500 65 "https://***redacted***/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.3 Safari/605.1.15" "192.168.4.254" response_time=0.003 proxy_host=app-service:4002 upstream_addr=172.18.0.6:4002

bbapps | {"level":"INFO","timestamp":"2025-02-22T07:49:12.902Z","service":"@budibase/server","req":{"method":"GET","url":"/app/preview","correlationId":"a1ea97f0-6c45-4472-9a71-e264be97b677"},"res":{"status":500},"err":{"type":"Error","message":"failed with status code 500","stack":"Error: failed with status code 500\n at ServerResponse.C (/app/dist/index.js:484:2529)\n at ServerResponse.emit (node:events:530:35)\n at ServerResponse.emit (node:domain:489:12)\n at ServerResponse.emit (/app/node_modules/dd-trace/packages/datadog-instrumentations/src/http/server.js:46:19)\n at onFinish (node:_http_outgoing:1027:10)\n at callback (node:internal/streams/writable:766:21)\n at afterWrite (node:internal/streams/writable:710:5)\n at afterWriteTick (node:internal/streams/writable:696:10)\n at process.processTicksAndRejections (node:internal/process/task_queues:81:21)"},"responseTime":3,"msg":"request errored"}

[andlil]

Sometimes the holes in the Swiss cheese lines up...

In my case creating a public application, upgrading the docker images and app and then changing the access rights for budibase from internal access to external broke just one thing, the preview.

It was the last step that broke it, in this case external access policy in traefik had "Referrer-Policy: strict-origin" vs internal that had the default "Referrer-Policy: strict-origin-when-cross-origin".

You always learn something new.