Skip to content
This repository has been archived by the owner on Dec 7, 2022. It is now read-only.

Safer handling of Accept headers #84

Merged
merged 1 commit into from Jan 22, 2018
Merged

Safer handling of Accept headers #84

merged 1 commit into from Jan 22, 2018

Conversation

mibanescu
Copy link
Member

@@ -77,7 +78,8 @@ def name_redirect(relative_path):
if schema2_data or manifest_list_data:
# if it is a newer docker client it sets accept headers to manifest schema 1, 2 and list
# if it is an older docker client, he doesnot set any of accept headers
accept_headers = request.headers.get('Accept')
accept_headers = get_accept_headers(request)
log.debug("Accept: %s", accept_headers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove the log statement, this information will not help anyone without a deep understanding of docker engine insides

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't anything about docker/crane, but I think someone that someone who turns on debug logging would have that deep understanding and want logging like this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with bmbouter. More than once I wanted to have more information, and I would prefer to do that without changing code (just changing config). That being said, I shouldn't log.debug twice.

Copy link
Member

@ipanova ipanova Jan 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not about docker/crane or pulp related but about docker-engine, the client for pulling the docker content and docker api. I still kinda think this is not very helpful, but if we want to keep this then please at least update to a more meaningful message something like " Accept headers sent from docker client" or "Accept header sent during docker pull"

accept_headers = request.headers.get('Accept')
if not accept_headers:
return []
log.debug("Accept: %s", accept_headers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about leaving just one log statement with "Received Accept headers" or similar?

return []
log.debug("Accept: %s", accept_headers)
accept_headers = accept_headers.split(',')
return set(x.strip() for x in accept_headers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for header in accept_header i find easier to read, in general i would avoid x,y,i, etc variable names.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agree, but for comprehension I find it concise enough. If you care deeply I can change it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really. it's just my personal preference of the pattern.

@@ -125,3 +127,12 @@ def handle_error(error):
response.headers['Content-Type'] = 'application/json'
response.status_code = error.status_code
return response


def get_accept_headers(request):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add doc block

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

headers = {'Accept': 'application/vnd.docker.distribution.manifest.v2+json'}
response = self.test_client.get('/v2/redhat/foo/manifests/1.25.1-musl', headers=headers)
# #3303: verify multi-valued headers too
# manifest lists are evaluated first, so pass a longer media type that
Copy link
Member

@ipanova ipanova Jan 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you elaborate more on this please?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code first checks if manifest_list_mediatype is in accept_headers. If the client sent a string that includes 'application/vnd.docker.distribution.manifest.list.v2+json like in my +junk test, as well as a valid manifest v2 media type, then you'd get a false match for a manifest list.

# #3303: verify multi-valued headers too
# manifest lists are evaluated first, so pass a longer media type that
# matches the manifest list as a prefix
headers = {'Accept': 'application/vnd.docker.distribution.manifest.list.v2+jsonjunk,application/vnd.docker.distribution.manifest.v2+json'} # noqa
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think +jsonjunk would be a valid mediatype sent from docker client :) max what you can have is +json or +prettyjws

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's with a civilized client. As a server, you should always check the inputs from the client. This is not a realistic example, just like this patch is not fixing something broken now.

Copy link
Member

@ipanova ipanova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mibanescu
Copy link
Member Author

All requested changes have been done.

@ipanova ipanova merged commit cf972a3 into pulp:master Jan 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants