Unable to display OctoPrint inside Home Assistant iframe

The logs seem to think everything is ok:

2020-10-26 15:37:37,445 - octoprint.access.users - INFO - Logged in user: admin
2020-10-26 15:37:37,447 - octoprint.server.api - INFO - Actively logging in user admin from ::ffff:192.168.0.68
2020-10-26 15:37:37,519 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.0.68
2020-10-26 15:37:37,702 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.0.68
2020-10-26 15:37:42,683 - octoprint.server.util.flask - INFO - Passively logging in user admin from ::ffff:192.168.0.68
2020-10-26 15:37:42,684 - octoprint.access.users - INFO - Logged in user: admin
2020-10-26 15:37:42,826 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.0.68
2020-10-26 15:37:43,303 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.0.68
2020-10-26 15:37:43,331 - octoprint.server.util.flask - INFO - Passively logging in user admin from ::ffff:192.168.0.68
2020-10-26 15:37:43,332 - octoprint.access.users - INFO - Logged in user: admin
2020-10-26 15:37:44,461 - octoprint.server.util.sockjs - INFO - User adminlogged in on the socket from client ::ffff:192.168.0.68

How do I turn off the login/authentication so I can try that? Can't seem to find it in the settings

So I added this to the config.yaml:

accessControl:
    enabled: true
    autologinLocal: true
    autologinAs: admin
    localNetworks:
    - 192.168.0.0/24

And when I hit the server in a chrome page it goes straight in without asking for username/password however when trying to access it from the home assistant iframe I get this:

The chrome debug says this:

image

And the octoprint log:

2020-10-27 18:23:30,814 - octoprint.server.util.flask - INFO - Passively logging in user admin from ::ffff:192.168.0.68
2020-10-27 18:23:30,815 - octoprint.access.users - INFO - Logged in user: admin
2020-10-27 18:23:31,788 - octoprint.server.util.sockjs - INFO - User admin logged in on the socket from client ::ffff:192.168.0.68

Any ideas?

well, been down this rabbit hole also...

Tried iframe and Nginx reverse proxies but all without success.

Anyone made some progress?

With the iframe you have to enable the option in OctoPrint to allow it.

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 :slight_smile:

thx :slight_smile: will have a look at the webcam and the refresh stuff, might be just some small adjustments :v:

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-cert which provided me with an .pem and .key file. 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.cfg file that looks like this:
    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
    
    
    Where the important sutff might be the explicit ssl binding, the SameSite cookie rewrite and the X-Scheme header.
  • I adjusted my docker compose file:
    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
    
    (thx to [HAProxy config with SSL for OctoPi Raspbian Stretch ยท GitHub]

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.