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

Comments

Projects
None yet
2 participants
@mouring
Copy link

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link
Author

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 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

Slight refactoring of API key evaluation in restricted_access decorator
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

This comment has been minimized.

Copy link
Owner

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 Jun 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.