Project

Profile

Help

Issue #3024

content creation API does not validate the hostname portion of Artifact URL

Added by dkliban@redhat.com about 2 years ago. Updated 6 months ago.

Status:
CLOSED - NOTABUG
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
Severity:
2. Medium
Version:
Platform Release:
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 26

Description

content.json has the following:

{
  "digest": "b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c",
  "path": "foo7.bar.gz",
  "artifacts": {"foo.bar.gz":"http://localhost:1234/api/v3/artifacts/7d39e3f6-535a-4b6e-81e9-c83aa56aa19e/"}
}

http POST http://localhost:8000/api/v3/content/example/ < content.json

This results in a succesful creation of content even though the port in the Artifact URL does not match the port on which Pulp is running.

This regression was introduced0 when fixing another problem with the API.

[0] https://github.com/pulp/pulp/pull/3161/files

History

#1 Updated by mhrivnak about 2 years ago

  • Sprint/Milestone set to 45
  • Triaged changed from No to Yes

#2 Updated by jortel@redhat.com about 2 years ago

Can someone elaborate on how this PR0 caused the regression and include a suggestion on how this needs to be fixed?

[0] https://github.com/pulp/pulp/pull/3161/files

#3 Updated by dkliban@redhat.com about 2 years ago

That PR removed the setting of the 'context' from the artifactsfield. The reason it was removed was because DRF was throwing an error saying that the context field was not allowed to be set. This inability to just set the context was a change in behavior from previous version of DRF. Without the context, the serializer doesn't know what the hostname for the server is. The solution is to figure out how the context can be passed in to the field.

As @mhrivnak mentioned during planning, it may be impossible to fix it and we'll just have to live with it.

#4 Updated by mhrivnak about 2 years ago

Imagining a scenario of Pulp running in a cluster and being accessed through a load balancer, we just have to keep in mind that the hostname and port being used by a client may be different than what the running process sees as the socket it is listening on.

#5 Updated by daviddavis almost 2 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to daviddavis

#6 Updated by daviddavis almost 2 years ago

  • Status changed from ASSIGNED to CLOSED - NOTABUG

I tested this out and it's actually consistent with the rest of our API. Here's another request I made—note that I am using a "badurl.com" for the repository url:

$ http POST http://localhost:8000/api/v3/repositorycontents/ repository='http://badurl.com/api/v3/repositories/foo/' content='http://localhost:8000/api/v3/content/example/1607fef2-d18b-4983-bfec-4fc2fc0ac492/'
HTTP/1.0 201 Created
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 158
Content-Type: application/json
Date: Mon, 16 Oct 2017 19:07:00 GMT
Server: WSGIServer/0.2 CPython/3.5.4
Vary: Accept, Cookie
X-Frame-Options: SAMEORIGIN

{
    "content": "http://localhost:8000/api/v3/content/example/1607fef2-d18b-4983-bfec-4fc2fc0ac492/",
    "repository": "http://localhost:8000/api/v3/repositories/foo/" 
}

After talking with @dkliban, we decided to close as not a bug.

#7 Updated by bmbouter over 1 year ago

  • Sprint set to Sprint 26

#8 Updated by bmbouter over 1 year ago

  • Sprint/Milestone deleted (45)

#9 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#10 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF