Octoprint: [Request] Restore disabling Access Control through low-level configuration options

[ucirello]

Adding username and password to OctoPrint is going to break my workflow. I use it inside a VPN, closed from the public. I understand the concern of people exposing their OctoPrint installations, but the same time, this more advanced workflow should not be disturbed.

My suggestion is to restore this functionality behind a low-level configuration flag. Somewhere deep in the configuration files that would disable it, therefore making it hard for people to unintentionally expose their OctoPrint instances.

[cp2004]

Are any of the options in config.yaml of any use to you? Maybe, the Auto Login Local (using VPN), or the basic auth headers? https://docs.octoprint.org/en/master/configuration/config_yaml.html#access-control

[GitIssueBot]

Hi @ucirello,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2020-11-24 16:10 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[ucirello]

@cp2004 -- I am going to double check if a combination of autologinLocal, autologinAs, and localNetworks works for me and I get back to you in one day.

[jneilliii]

You know there's also that little checkbox for remember me on the login page as well...minor inconvenience in the grand scheme of things compared to the headaches caused by people that are not responsible like you using a VPN solution.

[ucirello]

@jneilliii going through a login screen is not an option for me.

[foosel]

@jneilliii going through a login screen is not an option for me.

May I ask why?

[ucirello]

@foosel -- I am not in position to share details of my operation. Suffice to say that going through a login screen is not an option for me. The non-obvious alternative is use some kind of browser extension to drive the login for me - with all the consequences that it entails (like when OctoPi network fails and you have to reload the screen)

[foosel]

Well, you have autologinAs and automatic login based on provided basic auth headers at your disposal.

I will not bring back the option to run without access control enabled as experience has shown that within weeks someone will just make a tutorial on how to set this low-level configuration option and then I'm back to square one with regards of the constant overhead insecure setups like that exposed on the public internet cause me.

I'm happy to evaluate other options that go beyond either of the aforementioned two autologin options, but allowing to disable access control is not something I will bring back.

[ucirello]

I'm happy to evaluate other options that go beyond either of the aforementioned two autologin options, but allowing to disable access control is not something I will bring back.

Agreed.

As stated in https://github.com/OctoPrint/OctoPrint/issues/3803#issuecomment-724773880 - I get back to you in one day.

[ucirello]

@foosel -- It didn't do the trick - but for a different reason. There's no automatic setup/wizard for when I move enabled: false to enabled: true in the version I am running.

[cp2004]

You shouldn't change enabled to true, without having created a user first. OctoPrint 1.5.0rc1+ will have prompted you automatically to enable it - and that configuration option is ignored if it is set to false. This is the basis of my ticket #3804, to better handle when no users are configured but access control is enabled.

[ucirello]

@foosel @cp2004 -- I followed these steps: https://docs.octoprint.org/en/master/features/accesscontrol.html#rerunning-the-wizard
I managed to get the user created after re-running the wizard. After I got over this bump, the autoLogin features behave like I needed. Thanks.

@cp2004 -- makes sense. I think I slip through the cracks by misunderstanding the config.yaml documentation. In any case, I can see a way to keep my workflow. Thanks.