Issue #3024
closed
content creation API does not validate the hostname portion of Artifact URL
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 introduced[0] when fixing another problem with the API.
Updated by mhrivnak about 7 years ago
- Sprint/Milestone set to 45
- Triaged changed from No to Yes
Updated by jortel@redhat.com about 7 years ago
Can someone elaborate on how this PR[0] caused the regression and include a suggestion on how this needs to be fixed?
Updated by dkliban@redhat.com about 7 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.
Updated by mhrivnak about 7 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.
Updated by daviddavis about 7 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to daviddavis
Updated by daviddavis about 7 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.
.