hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Davis" <j...@FlyingDiamond.com>
Subject Re: Httpclient 3.0.1 + applet Security
Date Wed, 05 Jul 2006 06:50:54 GMT
Oleg,

Much thanks for the reply, indeed it help me track this one down, and I
think you'll be interested to know the answer.


> On Sun, 2006-07-02 at 00:39 -0600, Jeff Davis wrote:
>> Hi,
>>
>> I'm attempting to utilize the httpclient library inside an applet to
>> handle Get and Post requests to sites that may be different from the
>> originating site.  Thus I need to use a signed jar to open up the
>> security to allow this, which I am utilizing a self cert to sign the
>> jar.   I have discovered there is a problem with commons.logging-1.1
>> inside a jar that fails the sandbox security regardless if it is signed
>> or not.   The post I read indicating rolling the logging jar back to
>> version 1.0.4 would resolve that one, which I have done, and it did
>> solve the initial problem.  Since that time I get the following
>> exception listed below whether I use a singed jar or not, and regardless
>> whether I sign the httpclient jar or not as well.  So my question has
>> several parts:
>>
>
> Hi Jeff,
> I am by no means qualify as an expert in applets, as I usually would not
> touch applets with a two meter barge pole, but since no one else
> responded I'll try my best
>
>> 1) Is it be possible to utilize httpClient with proper certificates and
>> signing to operate inside an applet to access other sites?
>
> HttpClient is known to have been used successfully in applets before
>
>> 2) Is it ok to use HttpClient-3.0.1 with logging-1.0.4?
>
> Yes, it is. HttpClient requires commons-logging 1.0.2 or above.
>
>> 3) Which jars if any should be signed besides the application jar (i.e.
>> httpclient, codecs, and/or logging jars)?
>
> I believe all jars must be signed
>
>> 4) Is it possible to use a non authenticated self cert for jar signing
>> in this instance?
>
> I believe so

Yes, I have this working with a self cert.

>> 5) Assumin I read indicating rolling the logging jar back to
>> version 1.0.4 would resolve that one, which I have done, and it did
>> solve the initial problem.  Since that time I get the following
>> exception listed below whether I use a singed jar or not, and regardless
>> whether I sign the httpclient jar or not as well.  So my question has
>> several parts:
>>
>
> Hi Jeff,
> I am by no means qualify as an expert in applets, as I usually would not
> touch applets with a two meter barge pole, but since no one else
> responded I'll try my best
>
>> 1) Is it be possible to utilize httpClient with proper certificates and
>> signing to operate inside an applet to access other sites?
>
> HttpClient is known to have been used successfully in applets before
>
>> 2) Is it ok to use HttpClient-3.0.1 with logging-1.0.4?
>
> Yes, it is. HttpClient requires commons-logging 1.0.2 or above.
>
>> 3) Which jars if any should be signed besides the application jar (i.e.
>> httpclient, codecs, and/or logging jars)?
>
> I believe all jars must be signed
>
>> 4) Is it possible to use a non authenticated self cert for jar signing
>> in this instance?
>
> I believe so

Yes, I have this working with a self cert.

>> 5) Assuming this is actually possible, Can anyone shed some light on
>> fixing this for me?
>>
>
> You must explicitly grant HttpClient permissions to resolve DNS names
> and connect to remote hosts. There should be an entry similar to this
> one in the policy file of your application
>
> grant codeBase "file:${myapp_lib}/commons-httpclient.jar" {
>     permission java.net.SocketPermission "*", "resolve";
>     permission java.net.SocketPermission "localhost:*", "connect";
>     permission java.net.SocketPermission "mytargethost:*", "connect";
> };
>

Actually this was not necessary as long as the applet jar and other jars
are signed (I did not try it with only the applet jar signed).  I was able
to duplicate my method inside an applet successfully without modifying the
policy file - as long as I did not initiate the code as I explain below.

The security problem was originating with how this code in the applet was
called.  I was utilizing a javascript function to call a java method in
the applet that then attempted the code that failed the security checks. 
Even thought the javascript code was doing nothing to flag a security
check, the code in the applet was ran using the same security model as the
initial calling javascript wasg this is actually possible, Can anyone shed
some light on
>> fixing this for me?
>>
>
> You must explicitly grant HttpClient permissions to resolve DNS names
> and connect to remote hosts. There should be an entry similar to this
> one in the policy file of your application
>
> grant codeBase "file:${myapp_lib}/commons-httpclient.jar" {
>     permission java.net.SocketPermission "*", "resolve";
>     permission java.net.SocketPermission "localhost:*", "connect";
>     permission java.net.SocketPermission "mytargethost:*", "connect";
> };
>

Actually this was not necessary as long as the applet jar and other jars
are signed (I did not try it with only the applet jar signed).  I was able
to duplicate my method inside an applet successfully without modifying the
policy file - as long as I did not initiate the code as I explain below.

The security problem was originating with how this code in the applet was
called.  I was utilizing a javascript function to call a java method in
the applet that then attempted the code that failed the security checks. 
Even thought the javascript code was doing nothing to flag a security
check, the code in the applet was ran using the same security model as the
initial calling javascript was ran under, ignoring completely the security
model the applet was initialized under.  The javascript code needs to be
signed also.

I did not try modifying the policy file to see if that resolved the need
to sign the javascript or not.

Oddly enough your comments did indeed help steer me towards the solution
nonetheless, Thanks again!

Jeff



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


Mime
View raw message