Feature request: support for basic auth for octoprint

[Tirpitz93]

Version

future

Operating system type + version

ALL

Behavior

Enable connecting to octoprint behind a basic auth login.

AFAIK this is a new feature request.

[vojtechkral]

Can you please elaborate what you mean by:

Enable connecting to octoprint behind a basic auth login.

The standard way right now of authenticating to Octoprint is via the API key. Is this insufficient for you?

[Tirpitz93]

My octo server is behind ha proxy with basic auth, so I cant upload directly. the whole server is inaccessible until authentication has succeeded.

[vojtechkral]

@Tirpitz93 Ah, I see now what you mean. I'm not sure I see the reason for having this feature though. Can you describe your usecase or why you need it? Ie. specifically what the benefit is over authorization via an API key? Honestly I don't think we have enough cycles to implement it unless there is a convincing reason to do so...

[vojtechkral]

No response for a long time, closing. Feel free to comment further if needed.

[Tirpitz93]

because my printer is behind basic authentication before it even gets to the octoprint api authentication. AFAIK the only thing that would be required is sending authentication headers in the requests already being made.

[vojtechkral]

AFAIK the only thing that would be required is sending authentication headers in the requests already being made

Yes, that's the easy part. The thing I'm more worried about is how a GUI would be made for this. Two additional configuration options for Octoprint would be required, and the GUI is already kind of cluttered. We would also need to explain to other users that this login+password is not the one used for logging into Octoprint and that it's something completely else which most of them will probably never need. I'm not sure how this could be done without confusing people.

If I understand the setup right, the idea is to first authenticate with a proxy before passing through to Octoprint, because Octoprint's security is kind of questionable. That's reasonable, although I'd have two reservations:

• This only makes sense with https. If you're connecting to the proxy with http, the basic auth is completely moot as the username+password is sent in plaintext (just like the API key)
• This could also be done without basic auth using a subrequest. I haven't tried this myself, but I believe both haproxy and nginx can be configured to verify the API key via a subrequest before passing a request to Octoprint

I would prefer the latter to adding more config options. We could maybe write a tutorial on how to setup a proxy like that (when someone has time to do that :grinning:).

[Tirpitz93]

This has nothing to do with octoprint. In my setup basic authentication is managed through HAProxy, then I log in to octoprint again. which I manage through SSH. This means that octoprint continues to serve on plain http on the loopback IP and only the "secure" https haproxy faces the internet.

[vojtechkral]

@Tirpitz93 Yes, I understand. Maybe the best solution would be the ability to add arbitrary http headers.

[tracernz]

That's a rather peculiar setup. What I have done is install https://github.com/OctoPrint/OctoPrint-ForceLogin. So users must login to access anything through the web interface, but the API key still works for Slic3r etc. It does feel rather fragile relying on a plugin to load to enable auth requirement, and the default Octoprint setup is quite woeful in a number of ways in terms of security, compliance with FSH standard etc. sadly.

[vojtechkral]

Well, perhaps the proxy serves other purposes as well. Although I still think even then it would be better to have the proxy verify the API key rather than using the basic auth. I'm not very keen on an explicit support for basic auth, since it would be interface-wise confusing with Octoprint login, but we could add support for it via arbitrary http headers, which might be useful for other reasons too. Still a bit low-prio at the moment though. But I'll keep it in mind.

[Tirpitz93]

This seams to be a relatively common set up AFAIK, it is documented here: https://printoid.net/access-octoprint-from-the-internet/ as well as in other places. This one does mention the authkey in the config, but I haven't had a chance to test that set up. https://github.com/foosel/OctoPrint/wiki/Setup-on-a-Raspberry-Pi-running-Raspbian

[vojtechkral]

That first guide is kind of bad in that it advises to use http on port 80 for the public interface, ie. no https, in which case both the basic auth and the API key are pretty much useless, since they're both publicly visible. Whoever follows that guide without adding additional steps to make https work will end up exposing octoprint in an insecure way.

However with https the setup does make sense and we might want to add some kind of a support for it, preferably in a non-confusing way. It won't happen in the upcomming release, as it has a lot of features already, but I'll look into it afterwards.

[Tirpitz93]

I agree that https should be used. and in my case is. but that guide had a helpful diagram to illustrate the setup. I have added it inline here for others with the same question.

[alhazar313]

I too have haproxy enabled using that guide but configured with https and would love this feature

[tracernz]

Did you consider the Octoprint-ForceLogin plugin first? Then the API key can be used without login (as is normal e.g. for GitHub API). Maybe there are some issues with this plugin I'm unware of, and if so I'd like to hear about them as I'm currently using it.

[alhazar313]

I'd rather not have my security based on a plugin functioning, more secure using haproxy and https in my opinion.

[vojtechkral]

Well this is emabrassing - it turns out we proably already support HTTP Baisc Auth (through libcurl). If you guys want to try it out, just use an URL in this shape:

https://username:password@your-octopi-address.example.com/

I can't test it right now but if you can, it would be great if you could report whether it worked. Thanks!

Note: This only applies to the new OctoPrint implementation with libcurl since Slic3r PE 1.40.0 (currently beta).

[alhazar313]

I'll give it a shot this afternoon :D

[tracernz]

Ha! Good catch. :grin:

I'd rather not have my security based on a plugin functioning, more secure using haproxy and https in my opinion.

Yes, I am uneasy about that. I get the feeling that upstream OctoPrint are probably not that interested in patches to make it secure by default. :disappointed:

[vojtechkral]

Did anyone get the chance to test if this works?

[mcristina422]

@vojtechkral I was able to verify this worked in 1.40.1 against a nginx reverse proxy with basic auth

[vojtechkral]

@mcristina422 Great!

I'll still leave this bug open as a reminder to better document the feature / make it discoverable, because the way it is right now it's pretty much invisible...

[GreatGrizzly]

Having two extra fields in the Octoprint Upload section labeled Username and Password would be a great, easy edition to give this feature more exposure.

[Tirpitz93]

@GreatGrizzly that is what I was originally hoping for, but @vojtechkral does have a point with it being a point of confusion for new users. possibly if one was labeled Server login and one Octoprint login?

[Tirpitz93]

@mcristina422 I tested it and got it to work this morning too. would be nice to have a pair of fields instead, and then use a credential store to encrypt the login details.

[Sneakers82]

I've got Octoprint Version 1.3.9 HAPROXY setup using https on port 443. Configuring-HAProxy Slic3r PE 1.41.2+Win64 I tried the suggested https://user:pass@1.2.3.4/

I get the following Error Message:

Could not connect to Octoprint: Peer certificate cannot be authenticated with given CA certificates (60)

I've double checked my Username, Password and API Key.

I also tried whitelisting my remote IP address which I thought would be a better solution. My browser will load Octoprint without the additional auth step, but Slic3r still gives me the same error. I'm assuming the trouble must be with the unsigned SSL?

[vojtechkral]

@Sneakers82

I'm assuming the trouble must be with the unsigned SSL?

Yes. You'll need to import your self-signed certificate, this depends on the OS. On Windows, you'll need to import it into system certificate storage. On Linux / OS X there's a configuration line in Slic3r named HTTPS CA file where the cert file may be configured.

[Sneakers82]

@vojtechkral Thanks! I've added the self-signed certificate to the Trusted Root CA in windows. I used this guide. Octoprint was updated to 1.3.10

I get a new error message: SSL Connect Error (35) Uninstalling the Cert I go back to Error (60) I'm not sure about this one. Searching suggests curl is out of date but I doubt that. Is there a log I can view that might help me out?

[vojtechkral]

@Sneakers82 I'm afraid there's no way to get more detailed error message out of Slic3r at the moment since I'm not reading curl's verbose error buffer. (Which I very much should do and I'm putting it on my to-do list, it will be improved in the next release.)

In the meantime, you can download curl for windows and try to use it from the command line in the same way as Slic3r in order to diagnose the problem. Here's a command line that does the same thing as Slic3r's Test button:

curl -H 'X-Api-Key: <API-key>' https://<octoprint-host>/api/version

One thing that comes to mind is that by default curl verifies that the hostname matches the name in the certificate and we honor this default for security reasons. This means that if you're connecting to the OctoPrint via an IP address and the certificate instead specifies a hostname, it will be rejected.

[Sneakers82]

@vojtechkral Thank you! I owe you a beer!

I followed this guide and regenerated the cert using my IP for both the issuer and organization Everything works perfectly now!

[vojtechkral]

@Sneakers82 no problem, glad you got it working. Thanks for the links, that might be useful for other users...

[jmaeso]

Hi, could be that special characters are not escaped? at least in the password part:

I would prefer not to change my ha-proxy password in the octoprint settings 😅 Am I missing something?

[bubnikv]

basic auth is supported through the

https://username:password@your-octopi-address.example.com/

convention.

The following hint has been added to the tooltip "Print host behind HAProxy with basic auth enabled can be accessed by putting the user name and password into the URL " "in the following format: https://username:password@your-octopi-address/"); with 0a33aedc3adaa35886847504c607b843aae91d85

Raw URL was passed to libcurl, while it should have been URL encoded. This was fixed with 1b720db

The changes will be in PrusaSlicer 2.3.0-beta2. Closing.

[bubnikv]

The commit 1b720db was not correct, I had to revert it. I was calling the escape function over the complete http:/xxx/yyy line, which is incorrect. Certainly the http:// prefix must not be escaped.

I believe we have either to leave the escaping of special characters to you https://www.werockyourweb.com/url-escape-characters/

or we have to add new input fields for user / password, escape them and combine them into an URL. That is a lot more work though and I don't think that the user base is large enough to justify the effort.

[vojtechkral]

@bubnikv In newer curl versions (>= 7.62) there's curl_url_get() and curl_url_set() with the CURLUPART_USER and CURLUPART_PASSWORD flags [1] but I'm afraid there's again going to be the problem that some linux distros have curl older than that :-(

[bubnikv]

@vojtechkral

In newer curl versions (>= 7.62) there's curl_url_get() and curl_url_set() with the CURLUPART_USER and CURLUPART_PASSWORD flags [1]

Nice, thanks. Now somebody "just" needs to implement that.

Frankly it would be better, if Octoprint implements HTTP digest authentization, which is much safer than the plain authentization. https://github.com/OctoPrint/OctoPrint/issues/3854 We implement HTTP digest for the SL1 printer now, so the infrastructure is there.