well, been down this rabbit hole also...
Tried iframe and Nginx reverse proxies but all without success.
Anyone made some progress?
thanks, but after this you are stuck in the login-screen-loop.
My HA is ssl, and the iframe was also integrated as ssl.
I guess, all non-ssl could be working. But with ssl enabled the cookies won't get accepted, even when adjusting the config.yaml with samesite: none and cookies.secure: true.
Or am i missing something here?
1 Like
Take a look at this ticket, and see if you can make sense of it:
The comments below sound relevant to you, my link was a direct one.
Sounds to me like the browser can't validate the SSL, so it refuses to send anything useful to the server.
someone on Discord also seemed to indicate that 99% of these issues are related to SSL and if you look in your browser's developer console it may shed some light into the problem.
Using http only so not sure how SSL comes into play but yeah still not working to this day for me.
Well, a few cups of coffee later:
I created some Home Assistant addon that worked way better than all those iframe stuff. 10MegaBytes of RAM I waste happily!
It is based on some haproxy and by using some rewrite magic it was done.
Have a try, and please provide feedback: https://github.com/MaxWinterstein/homeassistant-addons/
2 Likes
This may even be unnecessary in the future as I think Frenck from the HA team is working on a bundled OctoPrint install with HA directly as well.
Just tried and it works as expected (except the camera as mentioned)
Also I updated an add-on in octoprint which caused it to restart but it didn't auto refresh - no biggie just refresh HA page but feedback is feedback 
thx will have a look at the webcam and the refresh stuff, might be just some small adjustments 
Any luck with webcam feed?
Also tried it with Nabu casa and it just displays the login screen but won't log in (could be something on my side, looking into it)
sadly not. All those path rewritings are really weird.
Have tried some but none did really work well. Might try the nginx way in the next version, but sadly this project ist not on my important things list, so this could take some time. Sorry.
Not a problem, it's just a nice to have.
Other methods can be used in the meantime.
I have tried your solution, but still getting the log in loop. Any suggestions what i might be doing wrong? Thanks
hello, have you now found a solution to the problem. I'm currently facing the same problem in the iframe in iobroker vis.
Thank you for your help
same here, something funky going on, bump
I think i found a solution? I have been having the same loop of the login screen.
In the ~/.octoprint/config.yaml file, I added/modified the server: configuration per here. I added the value for samesite: none to the config, but newer installs might have it set to lax?
server:
cookie:
samesite: none
This fixed the looping issue and I can view the octopi install from an iframe now (specifically Home Assistant)
every now and then i come back to this and think: this should work, somehow...
So, another coffee break, another try:
I use Octoprint within docker, managed via portainer. My Home Assistant installation is exposed through cloudflare tunnel.
- I created some self signed ssl certs (in my case i just hopped into the container and used
apt install ssl-certwhich provided me with an.pemand.keyfile. See ssl-cert › Wiki › ubuntuusers.de - I joined those both files to one (
cat /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-snakeoil.key > /octoprint/cert.pem) - I added a new
haproxy.cfgfile that looks like this:
Where the important sutff might be the explicit ssl binding, the SameSite cookie rewrite and the X-Scheme header.global maxconn 4096 user haproxy group haproxy daemon log 127.0.0.1 local0 debug # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/private # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). This list is from: # https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ # An alternative list with additional directives can be obtained from # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 defaults log global mode http option httplog option dontlognull retries 3 option redispatch option http-server-close option forwardfor maxconn 2000 timeout connect 5s timeout client 15min timeout server 15min frontend public bind :::80 v4v6 bind :::443 v4v6 ssl crt /octoprint/cert.pem use_backend webcam if { path_beg /webcam/ } #reqadd X-Forwarded-Proto:\ https default_backend octoprint backend octoprint http-request replace-path /(.*) /\1 http-request set-header X-Forwarded-Proto https if { ssl_fc } # Replace SameSite=Lax with SameSite=None in Set-Cookie headers http-response replace-header Set-Cookie "(.*);[ \t]*SameSite=Lax" "\1; SameSite=None" if { ssl_fc } http-request add-header X-Scheme "https" if { ssl_fc } # <-- IMPORTANT! option forwardfor server octoprint1 127.0.0.1:5000 backend webcam http-request replace-path /webcam/(.*) /\1 server webcam1 127.0.0.1:8080 - I adjusted my docker compose file:
(thx to [HAProxy config with SSL for OctoPi Raspbian Stretch · GitHub]version: '2.4' services: octoprint: image: octoprint/octoprint:latest ports: - 8055:80 - 8056:443 - 5000:5000 devices: - /dev/ttyUSB0:/dev/ttyUSB0 # - /dev/video0:/dev/video0 volumes: - /volume1/docker/octoprint:/octoprint - /volume1/docker/octoprint/haproxy.cfg:/etc/haproxy/haproxy.cfg environment: - ENABLE_MJPG_STREAMER=true - TZ=Europe/Paris
As the embedded iframe uses some self signed and only trusted cert, chrome complains about 'Not Secure' - that's fine for me. Adding the cert to the store might help, something like GitHub - FiloSottile/mkcert: A simple zero-config tool to make locally trusted development certificates with any names you'd like. does I guess.
For the moment chrome also complains about Third-party cookie will be blocked in future Chrome versions as part of Privacy Sandbox. - but this is an issue for later me and another coffee break.
Edit: It doesn't work, forget about this. I'm leaving the original text for posterity.
Here is another way to solve the problem.
Solution
Scenario
- I want to display Octoprint inside HomeAssistant iframe
- I want OctoPrint to be displayed inside OrcaSlicer Device tab
I couldn't make it work with HTTPS, specially the OrcaSlicer requirement. So I found a hacky way to fix it without HTTPS. You need to edit HAProxy config to rewrite the cookie header:
- Edit
/etc/haproxy/haproxy.cfg:sudo nano /etc/haproxy/haproxy.cfg - Change the
backend octoprintsection so it looks like this:
The important part is thebackend octoprint acl needs_scheme req.hdr_cnt(X-Scheme) eq 0 http-request replace-path ^([^\ :]*)\ /(.*) \1\ /\2 http-request add-header X-Scheme https if needs_scheme { ssl_fc } http-request add-header X-Scheme http if needs_scheme !{ ssl_fc } http-response replace-header Set-Cookie "(.*);[ \t]*SameSite=Lax" "\1; SameSite=None" option forwardfor server octoprint1 127.0.0.1:5000 errorfile 503 /etc/haproxy/errors/503-no-octoprint.httphttp-response replace-headerline.
Explanation
This is my understanding of what is going on.
TLDR: Setting config.server.cookie: "none" has no effect unless SSL is set up.
When a cookie is set using SameSite=Lax, it won't get sent back to the server when the page is loaded inside an iframe. And because CSRF is based on cookies, the login form won't work when inside an Iframe. To make it work we have to set SameSite=None, which we can do, in theory, setting config.server.cookie: "none" in the config . But because how flask works (the web server used by OctoPrint), setting it to "none" will just not add SameSite to the cookie header (source). And Chrome (and I guess other browsers) will assume SameSite=Lax when the SameSite is missing and served over HTTP.
By editing the cookie header before it is sent back to the client, we can replace SameSite=Lax with SameSite=None, tricking the browser into sending the CSRF back with the login data even when the page is loaded inside an iframe.
Just for the record, you have to thank browser vendors for that which while crippling browsers further and further for security reasons unless https is available have not yet thought about a good and end user compatible way to provide hosts on your private area network in your own home with certificates that your browser will accept (maybe with a minor additional warning) and that doesn't require you to register your own Domain at a place that allows you to automatically set TXTs on the domain's DNS. It sucks hard.
I actually found myself in a call with a Google Chrome dev a couple years back to address this, but there was absolutely no interest (and to be honest I'm not even sure they understood that setting up https is anything but easy for most people out there...).