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
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:
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
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.
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.
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
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.
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)
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.
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.
