hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber" <ROLWE...@de.ibm.com>
Subject Re: NTLM class
Date Thu, 14 Aug 2003 12:27:32 GMT
Hello Adrian,

these lines may indeed be responsible for some of the
configuration problems. In particular, it introduces a
default dependency on the Sun implementation of JSSE,
which causes problems with IBM JDKs that come with
IBMs rather than Suns JSSE.
Adding the security provider should not be a problem for
running a program, since it will be added with lowest
priority. It probably was meant to simplify things for people
who forgot to configure the JSSE in their java.security
properties file.

I believe these initializations should be removed completely.
They can never have been more than a convenience in the
first place. As long as the property is not documented, it is
rather a trap than a convenience. And once it's documented
it becomes a nuisance rather than a convenience for those
people that have their JSSE configured correctly and now
have to remember changing that property as well if it's not
the Sun JSSE.

Rather than trying to add the JSSE provider, the HTTP
client should simply prerequisite a correctly installed
JSSE. This would also remove the side effect of changing
the JVM's security configuration by simply loading the
NTLM class.
The only negative impact I can think of is for those that
got SSL running without registering the JSSE provider
properly. These people would have the choice between
adding a line to their java.security file, or putting the three
lines of initialization code in their own program.
The first choice is better for creating an installation on a
particular machine, the second is better for packaging a
program with HTTP client and JSSE that has to run on
a variety of host JVMs. But those who care about this
difference will have done the appropriate thing anyway
and won't notice any change at all.

regards,
  Roland






Adrian Sutton <adrian@intencha.com>
14.08.2003 12:39
Please respond to "Commons HttpClient Project"
 
        To:     "Commons HttpClient Project" 
<commons-httpclient-dev@jakarta.apache.org>
        cc: 
        Subject:        NTLM class


Howdy all,
In the docs for the org.apache.commons.httpclient.NTLM class is the 
note:
@deprecated this class will be made package access for 2.0beta2

However the class is still public.  At this stage of the release should 
we just leave the class public for 2.0 and remove it in 2.1 (or 3.0?) 
or should we make it package access as planned?

Also, could someone a little more familiar with JCE and particularly 
with alternate JCE implementations enlighten me as to whether or not 
some of the problems people are having with using non-Sun JVMs or 
non-Sun JCE implementations could be related to the static section in 
NTLM.java.  In particular the lines:

String secProviderName = 
System.getProperty("httpclient.security.provider", 
"com.sun.crypto.provider.SunJCE");

java.security.Provider secProvider = 
(java.security.Provider)Class.forName(secProviderName).newInstance();

Security.addProvider(secProvider);

Since I don't think we actually document the property 
httpclient.security.provider anywhere (yet) I doubt people are setting 
it, and thus we'd be registering the SunJCE provider if it was anywhere 
on the class path.  I'd imagine that may cause a few problems, but I 
know practically nothing about JCE so hopefully I'm wrong.

Regards,

Adrian Sutton.
----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: 
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: 
commons-httpclient-dev-help@jakarta.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message