Authentication failure after upgrade to 11.0.0 with Maven #7108
Comments
HttpClient is handed over the credentials for the hostedSuppressionUrl. Can you check whether your server responds with the authentication challenge? |
Thank you for the clarification. See the following curl request as example of the scenario rejected by SAXParser: |
|
Check the accompanying HTTP code, because given your stacktrace it looks more like that page gets served with an HTTP responsecode of the 2xx or 3xx range |
Correct these are the response details: When sending a request to Microsoft Azure DevOps without providing authentication credentials, it redirects to the login page using status code 302 while at the same time requesting authentication. If you however do provide invalid credentials, the response is 401 in combination with an authentication challenge: Does this simply mean that this plugin no longer supports authentication to Microsoft Azure DevOps services? |
|
I'm facing the same problems. Reverted the plugin to 10.0.4 and the DOCTYPE errors are gone. Trying to download the suppression file from a Azure Devops url. Any workaround available? |
|
bump! anybody willing to answer my question above? or @martijndebruijn 's question? |
|
@aikebah any clue on this one? |
|
Need to finish up my local pending changes to make apache httpclient use pre-emptive auth, but basically the root cause appears to be the server misbehaving in the context of HTTP protocol (not giving an http 401, but redirecting with 302 to webbased authentication page so that httpclient's credentials lookup never kicks in) Hope to finish that up later this week and put up a branch that hopefully someone can build a private snapshot from to validate my assumption that pre-emptive auth will solve the issue. |
|
Thanks - I wanted to make sure someone had this, even if it is going to take a bit of time to solve. |
|
@mdvalk-quintor Would you be able to test a privately built snapshot from the |
|
@aikebah
<suppressionFiles>
<suppressionFile>http://xxxxxxxxx:8080/basic302/suppressions.xml</suppressionFile>
</suppressionFiles>
<suppressionFileUser>my-username</suppressionFileUser>
<suppressionFilePassword>my-secret-password</suppressionFilePassword>5. dependency-chek failed: Suppression server logs: ➫ it seems the client reacts to the challenge but still without the credentials same project, with a server that returns 401 for the challenge, works: if you want I can propose a PR to fix this, let me know |
|
@ftiercelin HostedSuppression credentials are currently only supported via the properties file, so it's logical that your attempt failed. The suppressionFileUser/Password are used for configuring the user suppression files (during suppression analyzer run) download's authentication. |
|
@aikebah sorry but I'm confused by your comment #7108 (comment). |
|
Sorry for the confusion... browsing back in the comments... suppressionUser/Password should be usable for the mentioned usages to authenticate for the suppressionFiles. I got distracted by the parallel conversations regarding a custom hostedSuppressions location (for the CLI using the advanced parameter Authentication information for that hostedSuppressionsUrl can currently only be configured in the properties (as there are no configuration parameters in the various tools yet, but the core code is in to also allow user/password authentication for such a cached resource) |
|
Not sure how I managed to close this ticket unintentionally |
@ftiercelin Can you double-check that you actually used the dependency-check that you just mvn installed? I don't have a server stub to replay the whole, but have a squid-proxy in the middle, and with nothing is listening on port 80 of the configured host I get a proper pre-authenticated request in the proxy logs <suppressionFiles>
<suppressionFile>http://rajah.fritz.box/filter-me.xml</suppressionFile>
</suppressionFiles>
<suppressionFileUser>foo</suppressionFileUser>
<suppressionFilePassword>bar</suppressionFilePassword>yields In my squid proxy logs (and following that results in a failure as there is still a bug lurking in the code with respect to proxy-authentication in case of suppression-file downloads with suppressionFile credentials specified, so it breaks on a proxy 407; After fixing that up locally (still need to tidy it up a bit before pushing) it fails with a 503 due to proxy also being unable to connect to my server (as nothing is running on port 80) |
|
@aikebah ,
I have a server with several endpoints, among them:
(none of the endpoints actually check the user/password, so the value of the b64 encoded string after with the /basic/ endpoint, plugin exec succeeds, server logs are: with the /basic302/ endpoint, plugin execution fails and server logs are: |
|
Decided to try and replicate with a very basic java HttpServer implementation (https://gist.github.com/aikebah/27844a6c792bf6744b2ad09368244245) and fail to reproduce what you observe. My server logs indicate that it directly receives the basic auth: Are you sure that your stub-server processes all the headers? |
|
Hi @aikebah, it seems your execution is doing a preemptive auth, otherwise we would see first an unauthenticated error then the client retrying. Here are the full logs for a server that returns a HTTP-302: and the logs for one that returns HTTP-401 with WWW-Authenticate: Would you be running your test with something like |
|
@aikebah, in case you'd like to test with the server I have been testing with: https://github.com/ftiercelin/SuppressionServer |
|
@ftiercelin the httpclient5 branch has code that by and of itself should pre-empt due to adding pre-initialized basic authentication to the authcache. Was the crux of the change on the httpclient5 branch with respect to pre-emptive authentication. No clue why it works on my system but appears to do nothing on yours. |
|
Tried with your server stub... and that appears to also work fine for me <suppressionFiles>
<suppressionFile>http://localhost:8080/basic/suppressions.xml?full</suppressionFile>
<suppressionFile>http://localhost:8080/basic/suppressions.xml</suppressionFile>
<suppressionFile>http://localhost:8080/basic302/suppressions.xml?full</suppressionFile>
<suppressionFile>http://localhost:8080/basic302/suppressions.xml</suppressionFile>
</suppressionFiles>
<suppressionFileUser>foo</suppressionFileUser>
<suppressionFilePassword>bar</suppressionFilePassword>yields in the server Running on: Could it be that in some way you've disabled Apache HTTPClient AuthCache usage? |
|
Here, running on: Could it be that in some way you've disabled Apache HTTPClient AuthCache usage? Trying on another system to see if the same happens, but still fighting to build (can't recall all what I did on my main system to make the build to work) |
Neither would I, still curious to learn how we can see different behaviour among our systems. |
A basic install skipping all tests ( |
|
thanks @aikebah for the tip on skipping the tests. on my standard ubuntu machine, I can see the preemptive auth happening: I also tried upgrading the maven version (in case) on my WSL Ubuntu: ➫ still not providing the preemptive auth |
|
@aikebah I noticed you pushed some new code to /**
* Gets a HttpClientContext that supports pre-emptive authentication.
* @return A HttpClientContext pre-configured with the authentication cache build from the settings.
*/
public HttpClientContext getPreEmptiveAuthContext() {
final HttpClientContext context = HttpClientContext.create();
context.setCredentialsProvider(credentialsProvider);
context.setAuthCache(authCache);
return context;
}and final BasicScheme basicAuth = new BasicScheme();
basicAuth.initPreemptive(creds);
authCache.put(scopeHost, basicAuth);this did the trick: with the latest code, I no longer have issues with missing preemptive authentication on any of my systems. |
|
@ftiercelin Those were in from the start; I've recently added a commit to fix-up the broken proxy authentication for the suppression files (as that setup was using a dedicated just-in-time authentication configuration but forgot to include the proxy auth when configured (either through The snippets you quote are indeed the main parts to make the httpclient5 pre-emptively authenticate. Good to see it now also succeeds fine for you. |
Describe the bug
Since version 11.0.0 Apache Httpclient is used for web requests instead of plain java.
Configuration properties
suppressionFileUserandsuppressionFilePasswordare no longer respected. (and the alternative configuration usingsuppressionFileServerIdis neither respected).By intercepting the http request the owasp dependency-check maven plugin tries to make, we can verify that it skips authentication, even when authentication is provided by the user!
Version of dependency-check used
The problem occurs using version 11.0.0 of the maven plugin
Log file
To Reproduce
Steps to reproduce the behavior:
nc -l 8087Authorizationrequest header is missing!!Expected behavior
For step 4 in the reproduction steps above, we expect to see the Authorization header present on the request... e.g.:
Other comments
Authorizationheader is present in the requests!The text was updated successfully, but these errors were encountered: