fieldOfView / Cura-OctoPrintPlugin

Cura plugin which enables printing directly to OctoPrint and monitoring the process
GNU Affero General Public License v3.0
484 stars 74 forks source link

No active printer in Cura 4.8.0 macOS #214

Closed bjw-s closed 3 years ago

bjw-s commented 3 years ago

OS version: macOS Big Sur (11.0.1) Cura version: 4.8.0 OctoPrint version: 1.5.1 Cura-OctoPrintPlugin version: tried both 3.5 and latest master branch

Issue: I am trying to print directly from Cura to Octoprint, but I keep receiving an error message in the logs that there are no active printers. Am I maybe missing something in my setup?

Steps to reproduce:

Link to log file: https://pastebin.com/raw/epuwW4jN

fieldOfView commented 3 years ago

Did you try the version from the Marketplace?

Edit: Nevermind, that would get you the Nonetype object has no attribute state crash.

fieldOfView commented 3 years ago

See https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/192

In that issue, it turned out the netwrok connection of the OctoPrint instance had crashed. Can you confirm that OctoPrint is still accessible?

bjw-s commented 3 years ago

🎉 Your comment put me on the right track! The reverse proxy that I'm using automatically forces a http->https redirect if a TLS certificate is presented. After manually disabling that redirect everything works as it should! Thank you for this great plugin and responding so quickly!

fieldOfView commented 3 years ago

If your reverse proxy setup is easy to setup, I would like to reproduce this so perhaps I can make the plugin work with that kind of setup. It should work with HTTPS too, but perhaps the type of redirect you did was not caught.

fieldOfView commented 3 years ago

Aside: Looking at the log you provided, it looks like you did not clone the git repository with the --recursive flag so some modules are missing. The plugin falls back to what ships with Cura, but there may be some issues with that (that don't necessarily manifest on Ultimaker printers, but may on OctoPrint printers).

bjw-s commented 3 years ago

It's not super easy to deploy (I run Octoprint in my Kubernetes cluster), but I'm more than happy to guinea pig a potential solution. It seems as if the 308 redirect isn't being picked up.

I took a look at the QNetworkRequest FollowRedirectsAttribute documentation, and it seems http -> https redirects are not allowed:

Currently redirects that are insecure, that is redirecting from "https" to "http" protocol, are not allowed

As for the git clone: I reverted to the marketplace version now that I know what is causing the problem.

fieldOfView commented 3 years ago

it seems http -> https redirects are not allowed:

No, it is the other way around that is blocked. Http to https should work, https to http will not.

bjw-s commented 3 years ago

No, it is the other way around that is blocked. Http to https should work, https to http will not.

Doh... I should have read that better 🙂

fieldOfView commented 3 years ago

If you want to guineapig, you could try a 301 redirect instead of a 308. I vaguely remember having tested a 301 redirect.

bjw-s commented 3 years ago

I tried forcing a 301, but looks like the proxy will still forcibly send a 308 regardless of that setting for the https enforcement redirect.