Precondition
Describe the bug
When the X-Result-Detail HTTP header is dropped from Artifactory requests while in transit (by components like WAF), the WARN message in the log is wrong or at least misleading. For artifact with SHA 43515aa4b2f4bce7c431145e8c0a7bcc441e0532 it says
[WARN] No checksums found in artifactory search result of uri https://my-bin/artifactory/api/storage/gradle-plugins-extended-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar. Please make sure that header X-Result-Detail is retained on any (reverse)-proxy, loadbalancer or WebApplicationFirewall in the network path to your Artifactory Server
Yet, if you take said URI and check, you get the full JSON document including all checksums
...
"checksums" : {
"sha1" : "43515aa4b2f4bce7c431145e8c0a7bcc441e0532",
"md5" : "109c77960cac326bef39489f954aa048",
"sha256" : "09735d0a03d719b3a6e431ef414ef3c0dabe7b53ad597fae53e6e83667cb7bd5"
},
...
This sent me off to a wild goose chase until I built small IT and started debugging.
// Given
var dependency = new Dependency();
dependency.setSha1sum("43515aa4b2f4bce7c431145e8c0a7bcc441e0532");
var settings = new Settings();
settings.setString(Settings.KEYS.ANALYZER_ARTIFACTORY_URL, "https://my-bin/artifactory");
settings.setString(Settings.KEYS.ANALYZER_ARTIFACTORY_BEARER_TOKEN, "my-token");
Downloader.getInstance().configure(settings);
var artifactorySearch = new ArtifactorySearch(settings);
// When
var search = artifactorySearch.search(dependency);
// Then
assertThat(search, is(not(empty())));
Here's what happens.
ArtifactorySearch uses the Downloader to fetch-and-handle https://my-bin/artifactory/api/search/checksum?sha1=43515aa4b2f4bce7c431145e8c0a7bcc441e0532.
- It sends along the
X-Result-Detail: info header.
- Our WAF drops the header.
- Artifactory responds with a JSON array that contains two artifact URIs
{
"results" : [ {
"uri" : "https://my-bin:443/artifactory/api/storage/gradle-plugins-extended-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar"
}, {
"uri" : "https://my-bin:443/artifactory/api/storage/maven-central-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar"
} ]
}
ArtifactorySearchResponseHandler.handleResponse() with the help of Jackson parses this into a FileImpl. However, all fields but uri are null.
- We log
LOGGER.warn("No checksums found in artifactory search result of uri {}. ....", file.getUri()); with file.getUri() being the result URI instead of the fetched URI.
Version of dependency-check used
Latest i.e. main
Log file
See description above.
To Reproduce
Use my test case above.
Expected behavior
Until we can handle the dropped-X-Result-Detail-header case properly*, the log message should contain the original hash URL instead of the result artifact URL.
https://my-bin/artifactory/api/search/checksum?sha1=43515aa4b2f4bce7c431145e8c0a7bcc441e0532 instead of https://my-bin/artifactory/api/storage/gradle-plugins-extended-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar
* Proposal: take the first URI and fetch that one -> second Downloader invocation in ArtifactorySearch.search()
Additional context
We touched on this before when we discussed #7254.
Precondition
Describe the bug
When the
X-Result-DetailHTTP header is dropped from Artifactory requests while in transit (by components like WAF), the WARN message in the log is wrong or at least misleading. For artifact with SHA 43515aa4b2f4bce7c431145e8c0a7bcc441e0532 it saysYet, if you take said URI and check, you get the full JSON document including all checksums
This sent me off to a wild goose chase until I built small IT and started debugging.
Here's what happens.
ArtifactorySearchuses theDownloaderto fetch-and-handle https://my-bin/artifactory/api/search/checksum?sha1=43515aa4b2f4bce7c431145e8c0a7bcc441e0532.X-Result-Detail: infoheader.{ "results" : [ { "uri" : "https://my-bin:443/artifactory/api/storage/gradle-plugins-extended-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar" }, { "uri" : "https://my-bin:443/artifactory/api/storage/maven-central-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar" } ] }ArtifactorySearchResponseHandler.handleResponse()with the help of Jackson parses this into aFileImpl. However, all fields buturiare null.LOGGER.warn("No checksums found in artifactory search result of uri {}. ....", file.getUri());withfile.getUri()being the result URI instead of the fetched URI.Version of dependency-check used
Latest i.e.
mainLog file
See description above.
To Reproduce
Use my test case above.
Expected behavior
Until we can handle the dropped-
X-Result-Detail-header case properly*, the log message should contain the original hash URL instead of the result artifact URL.https://my-bin/artifactory/api/search/checksum?sha1=43515aa4b2f4bce7c431145e8c0a7bcc441e0532 instead of https://my-bin/artifactory/api/storage/gradle-plugins-extended-cache/io/projectreactor/netty/reactor-netty-core/1.2.7/reactor-netty-core-1.2.7.jar
* Proposal: take the first URI and fetch that one -> second
Downloaderinvocation inArtifactorySearch.search()Additional context
We touched on this before when we discussed #7254.