starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #1167] [Bug]: frame-ancestors 'none' blocks Ingress Integration in Home Assistant #843

New issue

Closed

opened 2026-05-07 00:14:17 +02:00 by BreizhHardware · 6 comments

BreizhHardware commented

2026-05-07 00:14:17 +02:00

Owner

Originally created by @Spegeli on GitHub (Apr 29, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1167

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

I am currently working on integrating BamBuddy into Home Assistant as an add-on.

https://github.com/Spegeli/homeassistant-app-bambuddy

The whole setup is actually working without any issues already.

However, I want to make the add-on available via Ingress so that it automatically appears in the Home Assistant sidebar. When you click on it, the interface should be displayed via an "iframe" so that BamBuddy can also be accessed remotely through Home Assistant.

And this is where the problem lies:

frame-ancestors 'none'

Unfortunately, this CSP directive prevents it from being embedded.

Regarding the Home Assistant integration under the Network settings, you've already implemented automatic detection of Home Assistant (when it's installed as an add-on).

Perhaps this logic could also be applied to the frame-ancestors directive to make the CSP slightly less strict when Home Assistant is detected, allowing it to be embedded via an iframe within the Home Assistant UI.

An alternative solution that comes to mind would be making this configurable via an environment variable (ENV), for example: ALLOW_IFRAME=true.

Expected Behavior

Upon clicking the link in the Home Assistant sidebar, Bambuddy should load within an iframe, providing direct access to the Bambuddy UI directly through Home Assistant.

Steps to Reproduce

Install BamBuddy as Home Assistant Addon (via https://github.com/Spegeli/homeassistant-app-bambuddy for example)
Enable Sidebar entry in the config:
Click on the Sidebar Link

Printer Model

None

Bambuddy Version

0.2.4b1

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Other

Operating System

Other

Relevant Logs / Support Package

No response

Screenshots

Additional Context

No response

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @Spegeli on GitHub (Apr 29, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1167 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description I am currently working on integrating BamBuddy into Home Assistant as an add-on. https://github.com/Spegeli/homeassistant-app-bambuddy The whole setup is actually working without any issues already. However, I want to make the add-on available via Ingress so that it automatically appears in the Home Assistant sidebar. When you click on it, the interface should be displayed via an "iframe" so that BamBuddy can also be accessed remotely through Home Assistant. And this is where the problem lies: frame-ancestors 'none' Unfortunately, this CSP directive prevents it from being embedded. <img width="1383" height="921" alt="Image" src="https://github.com/user-attachments/assets/802e2ece-78a7-49f0-bbbb-ea9d94af7244" /> Regarding the Home Assistant integration under the Network settings, you've already implemented automatic detection of Home Assistant (when it's installed as an add-on). <img width="396" height="496" alt="Image" src="https://github.com/user-attachments/assets/d9263e66-a2c1-4454-ae62-93dde0511355" /> Perhaps this logic could also be applied to the frame-ancestors directive to make the CSP slightly less strict when Home Assistant is detected, allowing it to be embedded via an iframe within the Home Assistant UI. An alternative solution that comes to mind would be making this configurable via an environment variable (ENV), for example: ALLOW_IFRAME=true. ### Expected Behavior Upon clicking the link in the Home Assistant sidebar, Bambuddy should load within an iframe, providing direct access to the Bambuddy UI directly through Home Assistant. ### Steps to Reproduce 1) Install BamBuddy as Home Assistant Addon (via https://github.com/Spegeli/homeassistant-app-bambuddy for example) 2) Enable Sidebar entry in the config: <img width="561" height="48" alt="Image" src="https://github.com/user-attachments/assets/a3583577-ee61-48cf-ae19-7eea21aa081a" /> 3) Click on the Sidebar Link <img width="277" height="85" alt="Image" src="https://github.com/user-attachments/assets/6c9bf897-db17-48a9-b85e-b6c4b897aed3" /> ### Printer Model None ### Bambuddy Version 0.2.4b1 ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Other ### Operating System Other ### Relevant Logs / Support Package _No response_ ### Screenshots <img width="576" height="37" alt="Image" src="https://github.com/user-attachments/assets/b6480a84-25a5-4033-b8fc-a0577edba03d" /> ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

2026-05-07 00:14:17 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:14:17 +02:00

Author

Owner

@Spegeli commented on GitHub (Apr 30, 2026):

I don't know if you already have a feature in BamBuddy that detects whether it is running as a Docker app within Home Assistant. If not, it would make sense to implement something like this for potential future features. For example, you could then set a rule like: 'If Home Assistant is detected, hide the update function inside BamBuddy.'

Because in that case, updates would be handled via the Home Assistant UI and not through the BamBuddy UI or shell.

I would open a separate feature request for this if necessary.

@Spegeli commented on GitHub (Apr 30, 2026): I don't know if you already have a feature in BamBuddy that detects whether it is running as a Docker app within Home Assistant. If not, it would make sense to implement something like this for potential future features. For example, you could then set a rule like: 'If Home Assistant is detected, hide the update function inside BamBuddy.' <img width="366" height="288" alt="Image" src="https://github.com/user-attachments/assets/69add948-52c6-4433-902e-a8d4aa7fd2a4" /> Because in that case, updates would be handled via the Home Assistant UI and not through the BamBuddy UI or shell. <img width="1037" height="585" alt="Image" src="https://github.com/user-attachments/assets/014878ba-e75f-46fb-adbd-3bfe68424333" /> I would open a separate feature request for this if necessary.

BreizhHardware commented

2026-05-07 00:14:17 +02:00

Author

Owner

@maziggy commented on GitHub (May 1, 2026):

Good catch — implemented in dev. Detection uses SUPERVISOR_TOKEN (the env var HA injects into every addon container), so it picks up HA addon installs cleanly and only HA addon installs.

Effect: the in-app "Update available" banner is suppressed when you're running under HA Supervisor (you already get the native HA update notification, no point duplicating it), and Settings → Updates now shows "Updates are managed by the Home Assistant Supervisor. Open Settings → Add-ons → Bambuddy in Home Assistant to install the new version." instead of the docker-compose snippet that you can't run from inside an addon container.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (May 1, 2026): Good catch — implemented in dev. Detection uses SUPERVISOR_TOKEN (the env var HA injects into every addon container), so it picks up HA addon installs cleanly and only HA addon installs. Effect: the in-app "Update available" banner is suppressed when you're running under HA Supervisor (you already get the native HA update notification, no point duplicating it), and Settings → Updates now shows "Updates are managed by the Home Assistant Supervisor. Open Settings → Add-ons → Bambuddy in Home Assistant to install the new version." instead of the docker-compose snippet that you can't run from inside an addon container. Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware commented

2026-05-07 00:14:17 +02:00

Author

Owner

@Spegeli commented on GitHub (May 2, 2026):

I haven’t tried the current daily beta yet, but I already read the changelog. I did see the part about the update Changes.
However, I still don’t find anything in there regarding the topic "frame-ancestors 'none'" and the change that prevented the Ingress / frame embedding into HA.
Has any change already been made there as well?

@Spegeli commented on GitHub (May 2, 2026): I haven’t tried the current daily beta yet, but I already read the changelog. I did see the part about the update Changes. However, I still don’t find anything in there regarding the topic "frame-ancestors 'none'" and the change that prevented the Ingress / frame embedding into HA. Has any change already been made there as well?

BreizhHardware commented

2026-05-07 00:14:17 +02:00

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

Yes — fixed in dev via #1191.

The catch is it's opt-in by env var, since the default has to stay strict for users running Bambuddy exposed to the internet. Set TRUSTED_FRAME_ORIGINS to your HA origin and Bambuddy will allow embedding from there (the Webpage panel, Ingress proxy, anywhere HA loads it from):

environment:
  - TRUSTED_FRAME_ORIGINS=http://homeassistant.local:8123

Comma-separated for multiple origins (e.g. local + Nabu Casa). Wildcards, paths, and non-http(s) schemes are rejected at startup with a log warning.

When set, X-Frame-Options is dropped and CSP becomes frame-ancestors 'self' <your-origins>;. When unset, behaviour is unchanged (strict, same-origin only).

@maziggy commented on GitHub (May 2, 2026): If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project! --- Yes — fixed in dev via #1191. The catch is it's opt-in by env var, since the default has to stay strict for users running Bambuddy exposed to the internet. Set `TRUSTED_FRAME_ORIGINS` to your HA origin and Bambuddy will allow embedding from there (the Webpage panel, Ingress proxy, anywhere HA loads it from): ```yaml environment: - TRUSTED_FRAME_ORIGINS=http://homeassistant.local:8123 Comma-separated for multiple origins (e.g. local + Nabu Casa). Wildcards, paths, and non-http(s) schemes are rejected at startup with a log warning. When set, X-Frame-Options is dropped and CSP becomes frame-ancestors 'self' <your-origins>;. When unset, behaviour is unchanged (strict, same-origin only).

BreizhHardware commented

2026-05-07 00:14:17 +02:00

Author

Owner

@Spegeli commented on GitHub (May 2, 2026):

I just installed the current daily version which includes TRUSTED_FRAME_ORIGINS. The environment variables feature has been implemented and set up, and it seems to be working so far.

[15:18:54] INFO: Setting TRUSTED_FRAME_ORIGINS: http://homeassistant.local:8123
2026-05-02 15:18:59,633 INFO [backend.app.main.security_headers] [-] TRUSTED_FRAME_ORIGINS: http://homeassistant.local:8123

When I now call up BamBuddy via the sidebar, the frame-ancestors 'none' error no longer appears. Instead, a completely white page shows up.

In the browser dev console, the following error messages appear:

Maybe this helps you:

Ingress Support Not Working – MIME Type & Asset Path Issues

Describe the bug
When enabling Home Assistant Ingress for the BamBuddy addon, only a white page is displayed. No content is rendered.

Environment

Home Assistant with BamBuddy addon via Ingress
Accessed through sidebar link

Console Errors
The browser developer console shows the following errors:

Wrong MIME type for static assets:

Refused to apply style from '.../assets/index-cR1fahwD.css' because its MIME type is 'text/plain' and strict MIME checking is enabled.

CSS and JS files are being served with text/plain instead of the correct MIME types. This appears to happen because the HA Ingress proxy does not preserve MIME types correctly when forwarding requests.

404 on Service Worker:

GET .../sw-register.js → ERR_ABORTED 404 (Not Found)

The service worker and other assets are being requested relative to / instead of the Ingress subpath (e.g. /api/hassio_ingress/xxxxx/).

Root Cause
The app is unaware of the Ingress subpath it is being served under. Home Assistant sets the X-Ingress-Path header on every request, which contains the base path the app should use for all asset references. Without reading this header and adjusting asset paths accordingly, all static files (CSS, JS, service worker) will return 404 or be served incorrectly.

Suggested Fix
The app needs to:

Read the X-Ingress-Path header from incoming requests
Use this value as the base path for all static assets and routing
Configure the web server (uvicorn/FastAPI) to serve static files relative to this dynamic base path

This is a known requirement for HA Ingress integration. Examples of how other addons handle this can be found in the Home Assistant Developer Docs on Ingress.

Note
The TRUSTED_FRAME_ORIGINS environment variable you recently added works correctly – the addon logs confirm the origins are being set properly. The remaining blocker is purely the Ingress path handling on the frontend/static asset serving side.

Thanks for the great work on BamBuddy!

If you use HA yourself, you can install the current daily build via https://github.com/Spegeli/homeassistant-app-bambuddy and test it yourself.

@Spegeli commented on GitHub (May 2, 2026): I just installed the current daily version which includes TRUSTED_FRAME_ORIGINS. The environment variables feature has been implemented and set up, and it seems to be working so far. [15:18:54] INFO: Setting TRUSTED_FRAME_ORIGINS: http://homeassistant.local:8123 2026-05-02 15:18:59,633 INFO [backend.app.main.security_headers] [-] TRUSTED_FRAME_ORIGINS: http://homeassistant.local:8123 When I now call up BamBuddy via the sidebar, the frame-ancestors 'none' error no longer appears. Instead, a completely white page shows up. <img width="1039" height="615" alt="Image" src="https://github.com/user-attachments/assets/7e95d493-7f1a-4f90-ba97-f6a80616beec" /> In the browser dev console, the following error messages appear: <img width="651" height="245" alt="Image" src="https://github.com/user-attachments/assets/eaf88b2a-786c-44a0-91f8-efaff1333d34" /> Maybe this helps you: ## Ingress Support Not Working – MIME Type & Asset Path Issues **Describe the bug** When enabling Home Assistant Ingress for the BamBuddy addon, only a white page is displayed. No content is rendered. **Environment** - Home Assistant with BamBuddy addon via Ingress - Accessed through sidebar link **Console Errors** The browser developer console shows the following errors: <img width="651" height="245" alt="Image" src="https://github.com/user-attachments/assets/eaf88b2a-786c-44a0-91f8-efaff1333d34" /> 1. **Wrong MIME type for static assets:** ``` Refused to apply style from '.../assets/index-cR1fahwD.css' because its MIME type is 'text/plain' and strict MIME checking is enabled. ``` CSS and JS files are being served with `text/plain` instead of the correct MIME types. This appears to happen because the HA Ingress proxy does not preserve MIME types correctly when forwarding requests. 2. **404 on Service Worker:** ``` GET .../sw-register.js → ERR_ABORTED 404 (Not Found) ``` The service worker and other assets are being requested relative to `/` instead of the Ingress subpath (e.g. `/api/hassio_ingress/xxxxx/`). **Root Cause** The app is unaware of the Ingress subpath it is being served under. Home Assistant sets the `X-Ingress-Path` header on every request, which contains the base path the app should use for all asset references. Without reading this header and adjusting asset paths accordingly, all static files (CSS, JS, service worker) will return 404 or be served incorrectly. **Suggested Fix** The app needs to: 1. Read the `X-Ingress-Path` header from incoming requests 2. Use this value as the base path for all static assets and routing 3. Configure the web server (uvicorn/FastAPI) to serve static files relative to this dynamic base path This is a known requirement for HA Ingress integration. Examples of how other addons handle this can be found in the [Home Assistant Developer Docs on Ingress](https://developers.home-assistant.io/docs/add-ons/presentation#ingress). **Note** The `TRUSTED_FRAME_ORIGINS` environment variable you recently added works correctly – the addon logs confirm the origins are being set properly. The remaining blocker is purely the Ingress path handling on the frontend/static asset serving side. Thanks for the great work on BamBuddy! If you use HA yourself, you can install the current daily build via https://github.com/Spegeli/homeassistant-app-bambuddy and test it yourself.

BreizhHardware commented

2026-05-07 00:14:18 +02:00

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

Thanks for the detailed breakdown — really helpful. Let me separate what I'm taking on from what I think belongs in your addon, because I want to keep Bambuddy core focused on things that benefit every deployment, not just one.

The TRUSTED_FRAME_ORIGINS half is working as intended. Your screenshot of the addon log confirms the env var parsed correctly and the frame-ancestors 'none' block is gone. That's #1191 done.

The white-page issue is a different category of problem — Bambuddy's frontend currently builds with absolute asset paths (/assets/..., /sw-register.js) which assumes the app is served at the host root. That breaks under HA Ingress, but it also breaks under any reverse proxy at a subpath: Traefik with a path prefix, nginx location /bambuddy/, Synology / Unraid reverse-proxy panels with subpaths, Cloudflare Tunnels with path routing, etc.

That part I'm willing to fix in core, because it's not addon-specific glue — it's a deployment constraint that affects a lot of self-hosters and removing it unblocks several scenarios at once. The change is making the Vite build use relative asset paths and registering the service worker relative to whatever base path it lands under. Probably a session of work plus careful testing across the standalone Docker / bare-metal / HA paths so I don't regress anyone.

Could you open a separate issue titled something like "Frontend: support being served at a non-root subpath (reverse proxy / HA Ingress)" and reference this thread? Frame it as the generic problem rather than HA-specific — that's how I want it tracked, since the fix benefits everyone behind a path-based proxy.

The HA-specific bits don't belong in Bambuddy core, though, and I want to be honest about where the line is:

X-Ingress-Path header handling — that's a HA-specific header. If your addon needs Bambuddy to honour a specific base path, the addon should set that up (env var, startup arg, or however you wire your container). Bambuddy core making decisions based on HA-injected headers is exactly the kind of thing I want to avoid — it makes the core harder to maintain and tests grow over time.
MIME type weirdness — most likely a side effect of the wrong asset paths and will resolve once relative paths land. If anything HA-Ingress-specific remains after that, it's an addon/proxy concern.
Service worker scope under a rotating Ingress token — the SW gets a fresh path every HA session because Ingress tokens rotate. That's a HA Ingress quirk; the addon side is the right place to deal with it (e.g., disable SW registration when running under Ingress, or accept that SW gets re-registered on each HA reload).

So the proposed split:

Bambuddy core: relative asset paths, relative SW registration. Generic fix, benefits everyone behind a path-based reverse proxy.
Your addon (Spegeli/homeassistant-app-bambuddy): Ingress path injection, X-Ingress-Path consumption, any HA-specific glue.

Once the core change lands, your addon should be able to do the rest itself — happy to coordinate and review what the addon side needs to look like.

In the meantime — the Webpage panel path with TRUSTED_FRAME_ORIGINS is a complete alternative for users who want Bambuddy in their HA dashboard right now. Different UX from Ingress (separate URL, no HA-side SSO), but it works today without any further changes on either side.

@maziggy commented on GitHub (May 2, 2026): Thanks for the detailed breakdown — really helpful. Let me separate what I'm taking on from what I think belongs in your addon, because I want to keep Bambuddy core focused on things that benefit every deployment, not just one. **The TRUSTED_FRAME_ORIGINS half is working as intended.** Your screenshot of the addon log confirms the env var parsed correctly and the `frame-ancestors 'none'` block is gone. That's #1191 done. **The white-page issue is a different category of problem** — Bambuddy's frontend currently builds with absolute asset paths (`/assets/...`, `/sw-register.js`) which assumes the app is served at the host root. That breaks under HA Ingress, but it also breaks under any reverse proxy at a subpath: Traefik with a path prefix, nginx `location /bambuddy/`, Synology / Unraid reverse-proxy panels with subpaths, Cloudflare Tunnels with path routing, etc. **That part I'm willing to fix in core**, because it's not addon-specific glue — it's a deployment constraint that affects a lot of self-hosters and removing it unblocks several scenarios at once. The change is making the Vite build use relative asset paths and registering the service worker relative to whatever base path it lands under. Probably a session of work plus careful testing across the standalone Docker / bare-metal / HA paths so I don't regress anyone. Could you open a separate issue titled something like **"Frontend: support being served at a non-root subpath (reverse proxy / HA Ingress)"** and reference this thread? Frame it as the generic problem rather than HA-specific — that's how I want it tracked, since the fix benefits everyone behind a path-based proxy. **The HA-specific bits don't belong in Bambuddy core, though**, and I want to be honest about where the line is: - **`X-Ingress-Path` header handling** — that's a HA-specific header. If your addon needs Bambuddy to honour a specific base path, the addon should set that up (env var, startup arg, or however you wire your container). Bambuddy core making decisions based on HA-injected headers is exactly the kind of thing I want to avoid — it makes the core harder to maintain and tests grow over time. - **MIME type weirdness** — most likely a side effect of the wrong asset paths and will resolve once relative paths land. If anything HA-Ingress-specific remains after that, it's an addon/proxy concern. - **Service worker scope under a rotating Ingress token** — the SW gets a fresh path every HA session because Ingress tokens rotate. That's a HA Ingress quirk; the addon side is the right place to deal with it (e.g., disable SW registration when running under Ingress, or accept that SW gets re-registered on each HA reload). So the proposed split: - **Bambuddy core**: relative asset paths, relative SW registration. Generic fix, benefits everyone behind a path-based reverse proxy. - **Your addon (`Spegeli/homeassistant-app-bambuddy`)**: Ingress path injection, X-Ingress-Path consumption, any HA-specific glue. Once the core change lands, your addon should be able to do the rest itself — happy to coordinate and review what the addon side needs to look like. **In the meantime** — the Webpage panel path with `TRUSTED_FRAME_ORIGINS` is a complete alternative for users who want Bambuddy in their HA dashboard right now. Different UX from Ingress (separate URL, no HA-side SSO), but it works today without any further changes on either side.

BreizhHardware referenced this issue

2026-05-07 00:16:21 +02:00

[PR #1029] [MERGED] v0.2.3 final #1155