You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Adrian Sutton <ad...@intencha.com> on 2003/08/14 12:39:35 UTC
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
Re: NTLM class
Posted by Ortwin Glück <or...@nose.ch>.
I find it bad pratice to set the JCE inside a totally lowlevel class.
The JCE should only be set by the application and not by HttpClient at all.
Odi
Adrian Sutton wrote:
> 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);
Re: NTLM class
Posted by Mike Moran <mi...@mac.com>.
On Thursday, August 14, 2003, at 03:36 pm, Michael Becke wrote:
> +1 for me as well.
Me too (+1, obviously non-binding). I'm about a quarter the way through
integrating rc1 into some code and the internal JCE hidden setup would
be a total spanner-in-the-works.
--
Mike
Re: NTLM class
Posted by Michael Becke <be...@u.washington.edu>.
+1 for me as well.
Mike
Ortwin Glück wrote:
> Adrian Sutton wrote:
>
>> My only concern with removing the code now is that we are so close to
>> a release and this is a change that clearly does have some fallout
>> even if we anticipate it to be very small.
>
> > We will need to make this *very* clear in the documentation
>
> I am +1 to remove the code from 2_0 branch anyway, because it is a major
> obstacle for integration. We must document the issue as you suggested,
> and include it in the release notes as well. Further documentation can
> be done by filing a Bug in Bugzilla, this will generate enough noise on
> the mailing list at the same time.
>
> Odi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
Re: NTLM class
Posted by Ortwin Glück <or...@nose.ch>.
Adrian Sutton wrote:
> My only concern with removing the code now is that we are so close to a
> release and this is a change that clearly does have some fallout even if
> we anticipate it to be very small.
> We will need to make this *very* clear in the documentation
I am +1 to remove the code from 2_0 branch anyway, because it is a major
obstacle for integration. We must document the issue as you suggested,
and include it in the release notes as well. Further documentation can
be done by filing a Bug in Bugzilla, this will generate enough noise on
the mailing list at the same time.
Odi
Re: NTLM class
Posted by Adrian Sutton <ad...@intencha.com>.
> I believe these initializations should be removed completely.
> They can never have been more than a convenience in the
> first place.
You are correct that they were to avoid having to avoid playing with
the java.security file. I originally wrote the NTLM support with our
applet in mind which absolutely must install without any active effort
on the users part so editing the java.security file is right out. On a
side note it is nigh on impossible to use JCE from an applet anyway
since it closes the jar file which later causes the class loader to
crash, so we actually have a modified HttpClient that uses a standalone
DES encryption class instead of JCE.
My only concern with removing the code now is that we are so close to a
release and this is a change that clearly does have some fallout even
if we anticipate it to be very small.
> 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.
We will need to make this *very* clear in the documentation as the
error message you get when the JCE provider isn't registered properly
is extremely misleading and gives no hint that the java.security file
should be edited.
> regards,
> Roland
If anyone does have any objections or know of likely problems removing
this code would cause please do speak up now.
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
Re: NTLM class
Posted by Roland Weber <RO...@de.ibm.com>.
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 <ad...@intencha.com>
14.08.2003 12:39
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<co...@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