Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require apikey even when access control is disabled #516

Closed
mouring opened this issue Jul 16, 2014 · 3 comments
Closed

Require apikey even when access control is disabled #516

mouring opened this issue Jul 16, 2014 · 3 comments

Comments

@mouring
Copy link

mouring commented Jul 16, 2014

Doing the following results in a HTTP/1.1 200 and the log file:
$ curl -D - 'http://10.0.0.9/downloads/logs/octoprint.log'

Where other API calls without the ?apikey= result in a HTTP/1.1 401
$ curl -D - 'http://10.0.0.9/api/logs/octoprint.log'

I assume this isn't intended behavior, as it isn't expected nor documented behavior.

@foosel
Copy link
Member

foosel commented Jul 17, 2014

Err....

$ curl -D - http://localhost:5000/downloads/logs/octoprint.log
HTTP/1.1 403 Forbidden
Date: Thu, 17 Jul 2014 10:39:30 GMT
Content-Length: 69
Content-Type: text/html; charset=UTF-8
Server: TornadoServer/3.0.2

<html><title>403: Forbidden</title><body>403: Forbidden</body></html>
$ ./run --version
OctoPrint version 1.2.0-dev-77-gf7f7d5c

Which git commit are you running there?

@mouring
Copy link
Author

mouring commented Jul 17, 2014

$ ./run --version
OctoPrint version 1.2.0-dev-77-gf7f7d5c

I suspect the difference (tested and provided it on my side) is this:

$ cat .octoprint/config.yaml
accessControl:
enabled: false
[..]

If accessControl is enabled it is protected. If disabled is isn't.

@foosel foosel added status:accepted and removed unreproduced No reproduction in a dev setting yet, further analysis blocked by that labels Mar 3, 2015
@foosel foosel changed the title Devel - Downloading Log link isn't protected by ?apikey= Require apikey even when access control is disabled Mar 3, 2015
foosel added a commit that referenced this issue Jun 3, 2015
Actual test whether key is provided or not happens in before_request handler of flask app, hence the more granular processing in the decorator was unecessary since around november '14. Adjusted to only do the actual processing necessary to replicate login_required behaviour/login users if necessary.

Closes #516 (actually, that was solved since introduction of the before_request handler which took that work off the hands of the decorator, but now it's properly documented too)
@foosel
Copy link
Member

foosel commented Jun 3, 2015

This has actually been fixed since 254145d but I only just noticed when I wanted to tackle this issue here. Took the opportunity to also slightly refactor things. But should be solved in current devel builds for some time now.

@foosel foosel closed this as completed Jun 3, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants