Skip to content

/ OctoPrint

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

Jump to bottom

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

This comment has been minimized.

Sign in to view
Copy link
Owner

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

This comment has been minimized.

Sign in to view
Copy link
Author

@mouring 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 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
@foosel
Slight refactoring of API key evaluation in restricted_access decorator
Loading status checks…
d2bca10 
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.

Sign in to view
Copy link
Owner

@foosel 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 Jun 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@mouring @foosel
You can’t perform that action at this time.