Cannot access repositories via basic auth proxy

Old Forum Archive
1

When I try to run the quick start sample with gradle , I get the below error. I have done the proxy configuration as per the gradle manual.

D:\gradle\gradle-1.2\samples\java\quickstart>gradle build :compileJava NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could no t load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file s pecified))

FAILURE: Build failed with an exception.

  • What went wrong: Could not resolve all dependencies for configuration ‘:compile’. > Could not resolve group:commons-collections, module:commons-collections, versi on:3.2.

Required by:

:quickstart:1.0

Could not HEAD ‘http://repo1.maven.org/maven2/commons-collections/commons-c ollections/3.2/commons-collections-3.2.pom’. Received status code 407 from serve r: Proxy Authentication Required

  • Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 4.406 secs

2

Can you double-check that you have correctly configured proxy authentication?

3

this is the gradle.properties which I have placed in the project root

systemProp.http.proxyHost= systemProp.http.proxyPort= systemProp.http.proxyUser= systemProp.http.proxyPassword= systemProp.http.nonProxyHosts=localhost systemProp.http.auth.ntlm.domain=

4

Well, the values matter too. :slight_smile:

Did you use ‘[domain]/[username]’ for ‘proxyUser’? In that case, you don’t have to set ‘http.auth.ntlm.domain’.

5

I have tried both the options

Option 1 : systemProp.http.proxyUser=UserName systemProp.http.auth.ntlm.domain=DomainName

Option 2 : systemProp.http.proxyUser=DomainName/UserName

6

I’ve upgraded Apache HttpClient from 4.2.1 to 4.2.2. You’ll be able to give it a try in tomorrow’s nightly build. If that doesn’t help, you may have to do some research on your own. Maybe you find something in the debug log (’-d’) that leads you to a solution.

7

OK Thanks. I will try that out tomorrow.

I already tried replacing httpclient and httpcore from 4.2.1 to 4.2.2 and renaming the jar file ( as it was suggested in some other forum ) - but i got the same error again.

I will try again with the new build .

From the debug , I could find that the the request was getting routed through the proxy ( just to confirm the setting took effect ) - but the credential were not getting applied.

8

I tried the nightly build . I get the same error again

The difference in the new build is that I get the below error continously .

D:\gradle\gradle-1.2\samples\java\quickstart>gradle build :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :jar UP-TO-DATE :assemble UP-TO-DATE :compileTestJava NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)) NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified))

9

hardluck - no resolution for proxy issue .

probably this is related to httpclient using kerberos over NTLM but the order could not be changed using system properties .

10

Gradle supports NLTM authentication via the JCIFS library, and we’ve been getting feedback that it works. It’s a hairy topic though, and maybe there is something specific about your proxy that makes it fail.

11

I wrote a test using httpclient jar to connect to mavenCentral and it is working. I found from the logs that BASIC scheme was used for authentication. But when I run through gradle , BASIC scheme is never being used for authentication . Wil check how to force httpclient to use BASIC scheme

12

I think I found out the problem.

When I test directly connecting to maven central using httpclient , below is the order of authentication schemes [NEGOTIATE, NTLM, BASIC]. Negotiate and NTLM fails , so BASIC is getting used and the authentication passes successfully

When I connect to maven repo using gradle build , the NTLM check gets triggered which I dont want to happen. Once the NTLM check is triggered , then the BASIC scheme is not getting applied

In the org.gradle.api.internal.externalresource.transport.http.HttpClientConfigurer ,

private void useCredentials(DefaultHttpClient httpClient, PasswordCredentials credentials, String host, int port) {

Credentials basicCredentials = new UsernamePasswordCredentials(credentials.getUsername(), credentials.getPassword());

httpClient.getCredentialsProvider().setCredentials(new AuthScope(host, port), basicCredentials);

NTLMCredentials ntlmCredentials = new NTLMCredentials(credentials);

Credentials ntCredentials = new NTCredentials(ntlmCredentials.getUsername(), ntlmCredentials.getPassword(), ntlmCredentials.getWorkstation(), ntlmCredentials.getDomain());

httpClient.getCredentialsProvider().setCredentials(new AuthScope(host, port, AuthScope.ANY_REALM, AuthPolicy.NTLM), ntCredentials);

LOGGER.debug(“Using {} and {} for authenticating against ‘{}:{}’”, new Object[]{credentials, ntlmCredentials, host, port});

}

If I comment the highlighted line of code , then it works . Since the NTCredentials are set , httpClient tries out the NTLM authentication without checking for the last option i.e. BASIC.

Shouldnt the NTCredentials be set only if the user has configured for NTLM ? If the user proxy is configured for

BASIC authentication scheme , then setting NTCredentials by default is forcing the httpClient to use NTLM .

13

I was under the impression that you do want NTLM authentication. Is that not the case?

14

Since this works for everyone else who is using basic authentication, I don’t think it’s wrong to configure NTLMCredentials every time. Question is why it doesn’t work for you.

15

Sorry - I did not read the debug logs correctly. My proxy needs BASIC authentication and not NTLM.

When I tested a stand alone program using http client, I noticed that NEGOTIATE and NTLM failed, and BASIC was successful in authenticating with the proxy. The reason why NTLM failed was because, in org.apache.http.impl.auth.NTLMScheme.authenticate() -> the credentials

get type casted to NTCredentials and the type casting fails because NTCredentials are not set. Therefore the org.apache.http.client.protocol.RequestAuthenticationBase.process tries to check the next option i.e BASIC

When I try debugging how org.gradle.api.internal.externalresource.transport.http.HttpClientHelper tries

to access the proxy,the org.apache.http.impl.auth.NTLMScheme.authenticate() does not fail and it returns some header .

Since a successful header is returned , org.apache.http.client.protocol.RequestAuthenticationBase.process()

does not try the third option BASIC . ( I feel something is not right in the way httpclient handles this . Refer the url -> http://old.nabble.com/-jira---Created--(HTTPCLIENT-1107)-Negotiate-authentication-failed,-but-not-trying-other-authentication-methods-td32068404.html. Probably a fix to this might be a big change as suggested by Oleg Kalnichevski )

I have also tried the gradle sample projects in a different environment with different proxy .Proxy error was thrown

there also. I have not analysed the logs.

My suggestion is that NTLMCredentials should not be configured every time unless this is specified by the user .

Kindly let me know your expert opinion.

16

Did anybody face this problem ? please share if there is any work around

17

After spending some time , I found only two solutions to the above problem.

1.Comment out setting NTLM Credentials in org.gradle.api.internal.externalresource.transport.http.HttpClientConfigurer -> useCredentials() . I am not sure whether this is correct since BASIC authentication works even without this change as per the previous comments for this issue.

  1. Set BASIC as the preferred scheme.I tried setting “systemProp.http.auth.preference=Basic” in gradle .properties , but it is not considerd by httpclient. The other way is to programatically set it in the HttpClient as below

List authpref = new ArrayList(); authpref.add(AuthPolicy.BASIC); client.getParams().setParameter(AuthPNames.PROXY_AUTH_PREF, authpref);

I could not find a way to configure or pass the above as system properties to gradle . The only option is modify gradle source code which will be a problem if i want to move to later versions.

So , giving up :frowning: in case if any body has any ideas ,please share

18

Same here (but did not find a work around).

Started from scratch. - All I wanted to do is to build spring webflow cloned from github [1].

Added my proxy configuration to the gradle.properties file:

systemProp.http.proxyHost=<…> systemProp.http.proxyPort=<…> systemProp.http.proxyUser=<…> systemProp.http.proxyPassword=<…>

And run “gradlew build”.

The first part went fine (proxy-configuration works!) Downloading http://services.gradle.org/distributions/gradle-1.3-bin.zip Unzippinig…

But then: “NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could not load configuration file C:\Windows\krb5.ini …”

Env: Win7 - jdk 1.6.0_37

[1] https://github.com/SpringSource/spring-webflow

19

Are you able to provide the full stacktrace for this error:

NEGOTIATE authentication error: Invalid name provided (Mechanism level: Could no

t load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file s

pecified))

Also the full --debug logs of the client/server interation would be helpful.

My suspicion is that NTLM authentication is failing in a way that aborts the rest of the authentication process. Normally if NTLM auth is not available then it will fail nicely, allowing the next protocol to be attempted. You see this when you don’t set the NTCredentials at all, but this isn’t an option for us.

So we need to know why in your particular environment, the NTLM authentication step is failing in a way that aborts the rest of the process. Seeing the full stack trace for the exception, as well as seeing the HTTP messages involved, should help us track this down.

20

Thanks for the response . find the stack trace below

https://gist.github.com/4175447