Plugin no longer follows 301 redirects (eg 80 -> 443)

[s7726]

Claims API key is no longer valid. I've produced new keys, no luck.

Let me know if there are any logs I can produce to assist.

[fieldOfView]

Please try pressing the Disconnect button, then entering (or requesting) a new key and pressing the Connect button/

[s7726]

The disconnect button is greyed out.

[fieldOfView]

Even if you click on your OctoPrint instance in the list?

[s7726]

Yeah, tried manually removing the API key also, including closing dialogue. It just gets repopulated. What would be the best easy to uninstall? I can try that and then installing again maybe? Although it would probably be a good idea to hunt down the actual issue.

[fieldOfView]

What you could try is go to the configuration folder (Help->Show configuration folder). Close Cura and open cura.cfg in a text editor. Remove the keys_cache line from the section named [octoprint].

In the folder machine_instances open the global.cfg file for your printer in a text editor. Remove the octoprint_id and octoprint_api_key lines.

Together this is a fresh start for the plugin.

The issue is that once the plugin has the wrong key for an OctoPrint instance, it is hard to convince it of using a different id. A confounding issue is that I am not in my office a lot these days which makes
it harder to work on the solution. But rest assured there will be a solution in an updated version soonish.

[s7726]

Did all that, got it cleared from the interface. Entering a fresh API key still giving me this message: EXTREME SPECULATION: It appears to be very immediate after pasting it in, like maybe it's failing some kind of local formatting check, rather than actually hitting the server and checking it. Edit: Checked that by adding a 'dummy' instance and it does try to contact it to verify the validity of the key.

[fieldOfView]

Could you try this development snapshot? Download the file and drop it into Cura as if you are opening a 3d model.

[fieldOfView]

Likely a duplicate of #165

[allyourcode]

FWIW, works for me. (I have not read this thread thoroughly, but...) WAG: Try updating Octoprint? The version string at the bottom of my UI is as follows:

OctoPrint 1.4.0 running on OctoPi 0.17.0

I think that is the latest.

I am running Cura 4.6.0, not the absolute latest, 4.6.1. Maybe try downgrading if you are running 4.6.1??

[fieldOfView]

The changes between 4.6.1 and 4.6.0 are very small, and they should not affect the OctoPrint plugin. Then again, I also can't see changes between 4.5 and 4.6 that would affect the plugin; the plugin is fairly self-contained, so using the same version of the plugin should give you the same result in both versions.

I did fix a usability issue in the development snapshot above. The issue made it hard to fix a broken API key. Unless @s7726 lets me know if the development snapshot fixes his issue or not, there is little I can do.

[s7726]

@fieldOfView I'll try to get on that, sorry I've been busy.

[Thisismydigitalself]

Same issue here. Cura 4.6 and latest OP plugin. Connection was not successful until i found this thread. disconnected first then connected with newly generated API and managed to connect successfully.

I wish OctoPrint plugin would give us more information in simple easy to read gui for knowing what goes on under the hood. The reason i was puzzled why I'm getting error 403 forbidden access even though the blue checkmark on the selected printer in Cura was always blue and checked so i was puzzled how come there is a connection but was not being able to send anything out.

Suggestion: I use two screens. Cura runs on Primary, Octoprint on the secondary. apps connected to same switch as my printers. For as long that i can remember there is a big delay from sending from cura till you see the file in Octoprint. this is something that i really wish to get improved. i wish to see instantly OctoPrint showing me the link is OK and that a file started uploading. i really don't like waiting few seconds which during that time i don't know what goes on. A progress bar on OctoPrint side would be lovely but this is, so I'm guessing, requires a supporting octoprint plugin.

Thank you for OP plugin. love it.

[fieldOfView]

Same issue here. Cura 4.6 and latest OP plugin.

It would have been great if you could have tested with the development snapshot I linked to above to see if the Disconnect/Connect button behaves better now. But now that you have already worked around the API key getting "wrong", it is harder to test that.

i wish to see instantly OctoPrint showing me the link is OK and that a file started uploading.

This is not something I can implement in Cura, it would have to be implemented in the default (web interface) client. However, the OctoPrint API only gives a client (such as the web interface and my plugin) access to its own files until they are completely uploaded.

[Thisismydigitalself]

the OctoPrint API only gives a client access to its own files until they are completely uploaded.

I hope foosel will find this useful to add some kind of a progress bar or a blinking blinky thingy so users will know something's going on for not waiting just to find out something went wrong and files did not go through. software needs to give a user feedback at all times.

Thx.

[s7726]

@fieldOfView finally got a chance to check out the dev build... No luck. Cura interface is still telling me the API key is not valid.

[jcustenborder]

@fieldOfView I gave the development snapshot a try and it seems to work for me. I clicked request and generated an api key for my user. Added it to octoprint and it's working properly.

2020-05-26 17:43:48,483 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice.connect [310]: Connection with instance octoprint-cr10max with url http://octoprint-cr10max.example.com:80/ started
2020-05-26 17:43:48,520 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [171]: Output Device octoprint-cr10max already added
2020-05-26 17:43:48,521 - WARNING - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice._setOffline [1120]: OctoPrint on octoprint-cr10max does not allow access to the printer state
2020-05-26 17:43:48,605 - ERROR - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice._onRequestFinished [1001]: OctoPrintOutputDevice got an error while accessing http://octoprint-cr10max.example.com:80/api/settings
2020-05-26 17:43:48,606 - ERROR - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice._onRequestFinished [1002]: You are not allowed to access OctoPrint with the configured API key.
2020-05-26 17:43:50,411 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._createAdditionalComponentsView [426]: Creating additional ui components for OctoPrint-connected printers.
2020-05-26 17:44:07,847 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction.testApiKey [263]: Trying to access OctoPrint instance at http://octoprint-cr10max.example.com:80/ with the provided API key.
2020-05-26 17:44:10,587 - WARNING - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._onRequestFinished [458]: Start polling for AppKeys decision
2020-05-26 17:44:15,583 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._onRequestFinished [484]: AppKey granted
2020-05-26 17:44:38,133 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction.testApiKey [263]: Trying to access OctoPrint instance at http://octoprint-cr10max.example.com:80/ with the provided API key.
2020-05-26 17:44:38,235 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._onRequestFinished [506]: API key accepted by OctoPrint.
2020-05-26 17:44:38,257 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [171]: Output Device octoprint-cr10max already added
2020-05-26 17:44:38,261 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [171]: Output Device octoprint-cr10max already added
2020-05-26 17:44:38,262 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice.connect [310]: Connection with instance octoprint-cr10max with url http://octoprint-cr10max.example.com:80/ started
2020-05-26 17:44:38,297 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [171]: Output Device octoprint-cr10max already added
2020-05-26 17:44:38,301 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [171]: Output Device octoprint-cr10max already added
2020-05-26 17:44:38,484 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice._onRequestFinished [835]: Set OctoPrint camera url to http://octoprint-cr10max.example.com:80/webcam/?action=stream

[s7726]

Did some wiresharking... It would appear the plugin is trying to hit the server on http (port 80), and not respecting the 301 return that it's receiving that would elevate the connection to https (port 443).

I guess I didn't notice that this happened in the midst of me securing my network and various services.

[s7726]

So I hate that Qt apparently just doesn't handle this gracefully. Here is a stack with what appears to be a solution. Seems like this would be a no-brainer for Qt to just handle. https://stackoverflow.com/a/51386788/1006048

[s7726]

And the Qt bug report https://bugreports.qt.io/browse/QTBUG-22677

[fieldOfView]

Ah, so there were two issues at play here. One, which is closely related to #165 made it hard to change an API key if it has somehow "gone bad". This has been confirmed fixed by @jcustenborder.

But @s7726 (also) has a different issue where redirecting from http port 80 to https port 443 no longer (?) works. Are you sure it worked before? With what version of Cura?

You can make it work by manually adding the instance skipping the redirect. In the manually added instance dialog, check the "Show reverse proxy options (advanced)" checkbox and check the "Use HTTPS" checkbox. Also enter the correct port number.

[s7726]

tada!

I meant that in general the plugin had worked prior. I do not believe it ever followed redirects.

Since I'm not using a 'reverese proxy' specifically I didn't think to hit that option, might be in need of a little UI/UX rework.

Also my certificate is self signed (silly google domains doesn't support the DNS record method of doing acme certs), and the plugin is not complaining, which I would expect it to since it's not signed against a valid authority (or even one that's in the local cert store. This is probably another issue though.

[fieldOfView]

I meant that in general the plugin had worked prior. I do not believe it ever followed redirects.

I am somewhat puzzled by why you would then conclude that the plugin stopped working in Cura 4.6, but a win is a win ;-). Are you okay if I close this issue?

Since I'm not using a 'reverese proxy'

Then what are you using? OctoPrint does not natively serve HTTPS, so there must be something between OctoPrint and your HTTPS port. How would you word it instead?

the plugin is not complaining, which I would expect

Currently the plugin is swallowing the complaint and just accepts any certificate. I realise that throws away an important reason for using HTTPS, but at this point it was either that or not having self-signed certificates work at all.

[fieldOfView]

Perhaps we should create a follow-up issue to see if following the redirect can be fixed.

[s7726]

I am somewhat puzzled by why you would then conclude that the plugin stopped working in Cura 4.6, but a win is a win ;-). Are you okay if I close this issue?

Apparently I last used it on 4.5, switched to https while doing a bunch of other network cleanup, and then installed and tried with 4.6, and the "only thing" I changed in cura was the version... I just didn't make the connection. That was my mistake.

Then what are you using? OctoPrint does not natively serve HTTPS, so there must be something between OctoPrint and your HTTPS port. How would you word it instead?

So yes in the sense that essentially all web apps use a reverse proxy to do the heavy lifting of serving etc., I am using a reverse proxy. The comment was just to say that having a separate checkbox to get to settings, to enable HTTPS is a little non-obvious when the rest of the internet 'just works' with HTTPS. It really falls into the "principal of least surprise".

Currently the plugin is swallowing the complaint and just accepts any certificate. I realise that throws away an important reason for using HTTPS, but at this point it was either that or not having self-signed certificates work at all.

This is a spot where I would expect to have an option to ignore self signed rather than ignoring by default.

Perhaps we should create a follow-up issue to see if following the redirect can be fixed.

Yes this should probably be broken out. I'll close this one, and see if I can edit the title (never tried in github before). Hopefully this chain (at least the last part where it all comes together) will help someone else.

[s7726]

Work around found... https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/168#issuecomment-634467101

[fieldOfView]

It was determined in #243 that this is likely due to an update of the Qt framework (which happened in Cura 4.9, I believe). I'll see what I can do to repair support for 301 redirects.

[tuplink]

for what its worth here is my nginx vhost, workaround ---- Show advanced options > Select use SSL, Change port to 443

---

server { listen 80; listen [::]:80; server_name octoprint.domain.com; return 301 https://octoprint.domain.com$request_uri; }

server { listen 443 ssl; listen [::]:443 ssl; server_name octoprint.domain.com; ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; location / { include /etc/nginx/internalnetworks.conf; proxy_pass http://**OCTOPRINTIP/; proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Scheme $scheme; proxy_http_version 1.1; client_max_body_size 0; } location /webcam/ { proxy_pass http://OCTOPRINTIP**:8080/; proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Scheme $scheme; proxy_set_header X-Script-Name /webcam; proxy_http_version 1.1; client_max_body_size 0; } }