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 #1096] [Bug]: spoolman ingress proxying doesnt work behind https #781

New issue

Closed

opened 2026-05-07 00:13:44 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:13:44 +02:00

Owner

Originally created by @jsapede on GitHub (Apr 23, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1096

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

setting up bambuddy behind proxy (traefik) serving https access breaks the "ingress" proxying of spoolman :

(index):1 Unsafe attempt to load URL http://192.168.0.38:7912/spool from frame with URL chrome-error://chromewebdata/. Domains, protocols and ports must match.

Expected Behavior

show spoolman content

Steps to Reproduce

Add spoolman with http://IP:PORT
fo to filament in sidebar

Printer Model

None

Bambuddy Version

0.2.3.2

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Other)

Relevant Logs / Support Package

No response

Screenshots

No response

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 @jsapede on GitHub (Apr 23, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1096 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description setting up bambuddy behind proxy (traefik) serving https access breaks the "ingress" proxying of spoolman : <img width="1904" height="903" alt="Image" src="https://github.com/user-attachments/assets/68f1c0dc-37e8-4976-ba4b-d3a1aa169c25" /> ```index-BIxtBfkP.js:8 Mixed Content: The page at 'https://*****/inventory' was loaded over HTTPS, but requested an insecure frame 'http://192.168.0.38:7912/spool'. This content should also be served over HTTPS. (index):1 Unsafe attempt to load URL http://192.168.0.38:7912/spool from frame with URL chrome-error://chromewebdata/. Domains, protocols and ports must match. ``` ### Expected Behavior show spoolman content ### Steps to Reproduce Add spoolman with http://IP:PORT fo to filament in sidebar ### Printer Model None ### Bambuddy Version 0.2.3.2 ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Other) ### Relevant Logs / Support Package _No response_ ### Screenshots _No response_ ### 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:13:44 +02:00

closed this issue
added the
wontfix
label

BreizhHardware commented

2026-05-07 00:13:44 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 23, 2026):

There's no need to add it to the sidebar. Just enable Spoolman integration via Settings -> Filament -> Filament Tracking and the link is automatically added to the sidebar.

Thanks for the report. What you're seeing is correct browser behaviour, not a Bambuddy bug: the browser refuses to embed an HTTP iframe inside an HTTPS parent page (mixed-content rule, independent of CSP). Bambuddy can't override that — nor should it.

The fix for your setup is to put Spoolman behind the same Traefik instance as Bambuddy with HTTPS (new public hostname + cert), then update the Spoolman URL in Settings to the HTTPS address. Once both are HTTPS, the iframe renders normally.

That said, the silent blank page isn't great UX — it gives you no hint what's wrong. In dev I've replaced the silent iframe with an inline warning card that detects the protocol mismatch and explains it, along with an "Open Spoolman in a new tab" workaround button (mixed-content only applies to embedded frames, so a standalone tab still works). Lands with the next daily build.

Closing as working-as-intended — the real fix for your setup is the HTTPS Spoolman deployment.

@maziggy commented on GitHub (Apr 23, 2026): There's no need to add it to the sidebar. Just enable Spoolman integration via Settings -> Filament -> Filament Tracking and the link is automatically added to the sidebar. ---- Thanks for the report. What you're seeing is correct browser behaviour, not a Bambuddy bug: the browser refuses to embed an HTTP iframe inside an HTTPS parent page (mixed-content rule, independent of CSP). Bambuddy can't override that — nor should it. The fix for your setup is to put Spoolman behind the same Traefik instance as Bambuddy with HTTPS (new public hostname + cert), then update the Spoolman URL in Settings to the HTTPS address. Once both are HTTPS, the iframe renders normally. That said, the silent blank page isn't great UX — it gives you no hint what's wrong. In dev I've replaced the silent iframe with an inline warning card that detects the protocol mismatch and explains it, along with an "Open Spoolman in a new tab" workaround button (mixed-content only applies to embedded frames, so a standalone tab still works). Lands with the next daily build. Closing as working-as-intended — the real fix for your setup is the HTTPS Spoolman deployment.

BreizhHardware commented

2026-05-07 00:13:45 +02:00

Author

Owner

@jsapede commented on GitHub (Apr 23, 2026):

putting spoolman in https with traefik will expose it worldwide. is adding a little proxy like caddy between bambuddy and spoolman will allow to manage https (selfsigned ?) without exposing spoolman ?

@jsapede commented on GitHub (Apr 23, 2026): putting spoolman in https with traefik will expose it worldwide. is adding a little proxy like caddy between bambuddy and spoolman will allow to manage https (selfsigned ?) without exposing spoolman ?

BreizhHardware commented

2026-05-07 00:13:45 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 23, 2026):

Yes, exactly — that's the standard self-hosting pattern, and the one I'd recommend. "HTTPS for Spoolman" does not mean "Spoolman on the public internet." Three ways to do it without exposing anything:

Caddy sidecar (simplest, ~5 lines of config) — one extra container on the same Docker network, binds to your LAN IP (e.g. https://192.168.1.50:7913), reverse-proxies to Spoolman over plain HTTP internally. Caddy auto-generates a local self-signed cert; accept it once in the browser and the iframe renders cleanly.
Re-use your existing Traefik — add a Spoolman router bound to an internal-only entrypoint (Docker network, or a LAN-bound entrypoint, not the public :443). Same Traefik instance, same wildcard cert if you have one, zero public exposure.
If you want trusted certs without browser warnings on your LAN, mkcert + Caddy works well.

The mixed-content rule doesn't care whether the HTTPS iframe is public or LAN-only — it just needs to be HTTPS.

@maziggy commented on GitHub (Apr 23, 2026): Yes, exactly — that's the standard self-hosting pattern, and the one I'd recommend. "HTTPS for Spoolman" does not mean "Spoolman on the public internet." Three ways to do it without exposing anything: 1. Caddy sidecar (simplest, ~5 lines of config) — one extra container on the same Docker network, binds to your LAN IP (e.g. https://192.168.1.50:7913), reverse-proxies to Spoolman over plain HTTP internally. Caddy auto-generates a local self-signed cert; accept it once in the browser and the iframe renders cleanly. 2. Re-use your existing Traefik — add a Spoolman router bound to an internal-only entrypoint (Docker network, or a LAN-bound entrypoint, not the public :443). Same Traefik instance, same wildcard cert if you have one, zero public exposure. 3. If you want trusted certs without browser warnings on your LAN, mkcert + Caddy works well. The mixed-content rule doesn't care whether the HTTPS iframe is public or LAN-only — it just needs to be HTTPS.