Fetching with an empty api key is allowed

[DavidVentura]

What were you doing?

1. Fetch the printer state with no apikey

        var url = 'http://octopi.labs';
        var _headers = new Headers();

        _headers.append('X-Api-Key', '');
        _headers.append("Content-Type", "application/json; charset=utf-8");

        fetch(`${url}/api/printer`, {'headers': _headers})
        .then(response => response.json())
        .then(json => console.log(json));

import requests
r = requests.get('http://octopi.labs/api/printer', headers={'X-Api-Key': ''})
print(r.text)

What did you expect to happen?

Get a 'invalid/misssing' apikey response

What happened instead?

Got a response ..

{…}
​
state: Object { flags: {…}, text: "Operational" }
​
temperature: Object { bed: {…}, tool0: {…} }
​
<prototype>: Object { … }

{
  "state": {
    "flags": {
      "cancelling": false, 
      "closedOrError": false, 
      "error": false, 
      "operational": true, 
      "paused": false, 
      "pausing": false, 
      "printing": false, 
      "ready": true, 
      "sdReady": false
    }, 
    "text": "Operational"
  }, 
  "temperature": {
    "bed": {
      "actual": 23.62, 
      "offset": 0, 
      "target": 0.0
    }, 
    "tool0": {
      "actual": 23.37, 
      "offset": 0, 
      "target": 0.0
    }
  }
}

Did the same happen when running OctoPrint in safe mode?

yes

Version of OctoPrint

OctoPrint 1.3.8

Operating System running OctoPrint

OctoPi 0.15.0

Printer model & used firmware incl. version

Not applicable

Browser and version of browser, operating system running browser

Chromium, Firefox on linux

Link to octoprint.log

nothing of value in the log

Link to contents of terminal tab or serial.log

nothing of value

Link to contents of Javascript console in the browser

--

Screenshot(s)/video(s) showing the problem:

--

I have read the FAQ.

[foosel]

Has already been fixed in 13ab34a, to be released with 1.3.10.

A bit of background on this: The API key requirement for anonymous access is somewhat stupid anyhow and to be removed in 1.4.0 - since even the bundled UI needs some key right now it in order to be able to contact the server in the first place, an anonymous UI API key is available by fetching the index page and also on the websocket to allow bootstrapping, kinda defeating the whole point of mandatory keys. And since we can't know the network situation in which an OctoPrint instance will run, we can't really whitelist client IPs or networks in any way. The original thought behind it was not to actually secure anything (kinda pointless considering the aforementioned UI hen-egg-issue and the fact that the APIs are accessibly anonymously, but restricted to read-only mode) but just to make it a tad more tricky to bombard the API in some kind of drive by scenario.

In anonymous mode you basically have the same rights on the API as if you were accessing the web page directly without being logged in. In 1.4.0 this will be tightened down further and allow people to take any kind of access away from anonymous users.

PS: In general it's btw better to get in touch about issues with potential security implications on private channels in order to not risk people abusing something before the developers have a chance to react and fix things.

[DavidVentura]

Do you have a release date planned for 1.3.10? Otherwise this could/should be backported into 1.3.9/1.3.8?

I am not seeing update prompts on my octoprint UI and even https://get.octoprint.org/latest points to 1.3.8

[foosel]

I plan to release 1.3.9 this week unless I get any reports in that indicate otherwise and the severity of this issue doesn't justify the enormous testing overhead of a hotfix release for 1.3.8 or yet another rc for 1.3.9.

As I said, this isn't allowing access to information that would otherwise be inaccessible and is functionality that is going to be removed in the future anyhow.

[foosel]

1.3.10 has been released.