[
http://jira.codehaus.org/browse/MNG-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=183620#action_183620
]
Jean-Marc Borer edited comment on MNG-4228 at 7/15/09 3:26 AM:
---------------------------------------------------------------
Guys,
I am perfectly understanding all your points, especially the licensing issues
withJCIFS, but it seems that my explanations are not enough clear. So let's
make it as clear as possible.
- We are sitting behind a proxy server which requires NTLM authentication. I
don't know if it is v1 or v2, but I have some insights (see below). All server
and clients are hosted on Windows machines.
- Maven 2.1.0 works where Maven 2.2.0 fails. According to your feedback, 2.2.0
has moved from Sun's http layer to Apache's httpclient 4.
- Meanwhile we have another product, Artifactory from http://www.jfrog.org/,
which uses httpclient that manages to authenticate with our proxy server. I
asked the developpers which version of httpclient they use in their product and
they said it is an unpatched/unmodified apache's httpclient 3.x.
- I made wrote a small example (see attached [2]) which uses httpclient 3.x
that authenticates successfuly with our proxy server. This makes me suppose
that our proxy server uses NTLMv1, because it supported (even tough partially)
by httpclient 3.x
- I retried with a modified version of httpclient that I found among the
httplcient issues (http://issues.apache.org/jira/browse/HTTPCLIENT-579) which
is supposed to improve NTLM support. I works fine too. However there are again
licensing issues.
Conclusion:
Why is then maven 2.2.0 no longer working? Problably because it uses httpclient
4.x and not httpclient 3.x. This would explain why artifactory has no problems
and maven 2.2.0 has. Something changed in version 4.x. Did they completely drop
the NTLM support? If yes, this are bad news.
JCIFS is no longer going to support the HTTP implementation
(http://jcifs.samba.org/src/docs/ntlmhttpauth.html). Instead they recommend to
use a commercial library (http://www.ioplex.com/jespa.html). We could afford to
buy the lib instead of dropping maven, but it still is unclear to me how to
tell httpclient 4.x to use jespa.
Letting the user to decide which implementation of HTTP layer to use is the
best option for me. Downgrade from httpclient 4.x to httpclient 3.x is not
really I good idea, even if it breaks NTLM authentication. One may argue here.
I understand the licensing issues with jcifs. But would it be an option to let
the end user download jcifs and make mave use it? Same question for jespa?
was (Author: jmborer):
Guys,
I am perfectly understanding all your points, especially the licensing issues
withJCIFS, but it seems that my explanations are not enough clear. So let's
make it as clear as possible.
- We are sitting behind a proxy server which requires NTLM authentication. I
don't know if it is v1 or v2, but I have some insights (see below). All server
and clients are hosted on Windows machines.
- Maven 2.1.0 works where Maven 2.2.0 fails. According to your feedback, 2.2.0
has moved from Sun's http layer to Apache's httpclient 4.
- Meanwhile we have another product, Artifactory from http://www.jfrog.org/,
which uses httpclient that manages to authenticate with our proxy server. I
asked the developpers which version of httpclient they use in their product and
they said it is an unpatched/unmodified apache's httpclient 3.x.
- I made wrote a small example (see attached [2]) which uses httpclient 3.x
that authenticates successfuly with our proxy server. This makes me suppose
that our proxy server uses NTLMv1, because it supported (even tough partially)
by httpclient 3.x
- I retried with a modified version of httpclient that I found among the
httplcient issues (http://issues.apache.org/jira/browse/HTTPCLIENT-579) which
is supposed to improve NTLM support. I works fine too. However there are again
licensing issues.
Conclusion:
Why is then maven 2.2.0 no longer working? Problably because it uses httpclient
4.x and not httpclient 3.x. This would explain why artifactory has no problems
and maven 2.2.0 has. Something changed in version 4.x. Did they completely drop
the NTLM support? If yes, this are bad news.
JCIFS is no longer going to support the HTTP implementation
(http://jcifs.samba.org/src/docs/ntlmhttpauth.html). Instead they recommend to
use a commercial library (http://www.ioplex.com/jespa.html). We could afford to
buy the lib instead of dropping maven, but it still is unclear to me how to
tell httpclient 4.x to use jespa.
Letting the user to decide which implementation of HTTP layer to use is the
best option for me. Downgrade from httpclient 4.x to httpclient 3.x is not
really I good idea, even if it breaks NTLM authentication. One may argue here.
I understand the licensing issues. But would it be an option to let the end
user download jcifs and make mave use it? Same question for jespa?
> [regression] Authorization failed: Not authorized by proxy.
> -----------------------------------------------------------
>
> Key: MNG-4228
> URL: http://jira.codehaus.org/browse/MNG-4228
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Settings
> Affects Versions: 2.2.0
> Environment: Windows XP, java version "1.6.0_04"
> Reporter: Marco Noto
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.2.1
>
> Attachments: NTLMV21.RAR, TestNTLMAuth.java
>
>
> I can not access any external repository using the version 2.2.0. If I go
> back to 2.1.0 everything works properly.
> For example:
> mvn -U eclipse:eclipse
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> [INFO] org.apache.maven.plugins: checking for updates from central
> [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be
> retrieved from repository: central due
> to an error: Authorization failed: Not authorized by proxy.
> [INFO] Repository 'central' will be blacklisted
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
