applet use of WL classes
Justin Johnson
I have the same problem, however I can not use this work around!
When Weblogic's classes aren't in a signed JAR HTTPS will not work.
I think this is because Weblogic is attempting to set one of there classes as
the URLStreamHanlder factory. I think that they get a Security Exception when
they do this.
When using the Plugin the default URLConnection (with https) is sun.plugin.protocol.jdk12.https.BrowserHttsURLConnection.
This class does not give you access to custom headers.
When using IE's VM the default class is a com.ms.net.winit.**something**. This
class let's you have access to the custom headers.
That is why SSL does not work using the plugin if Weblogic's classes aren't in
a signed JAR. When I put Weblogic's classes in the jar. The jar's size increases
to 13 megs.
The only thing that I can think of to do is to create our own security policy
on the client and allow classes that aren't in your signed jar to have permissions
to read write system properties (maybe just AllPermision). Then Weblogic's classes
that would be downloaded in the second jar (see below) would be able to set themselves
as the URLStreamHandlerFactory.
Does anyone know of any other solutions to this? Has anyone tested ssl using the
plugin w/ out opening the client's security using a policy file?
I don't think it would ever work (sun.plugin.protocol.jdk12.https.BrowserHttpsURLConnection
doesn't let WL have access to their custom headers).
Thanks,
Justin
"Joe Herbers" <jher...@synchrony.net> wrote:
>Thanks for the response on this. Our short-term fix is to provide a
>second
>jar that is *not* signed that contains the WebLogic classes. This doesn't
>help us get around the issue introduced in sp8 (where the class
>weblogic.net.http.Handler tries to invoke getProperties outside of a
>try/catch - the resulting AccessControlException brings down our applet)
>but
>is an ok workaround for now.
>
>Other people must struggle with how to include WebLogic classes in an
>applet
>jar - ?
>
>
>"Cameron Purdy" <cpu...@tangosol.com> wrote in message
>news:3a814e8c$1...@newsgroups.bea.com...
>Joe,
>
>I checked with "the expert" on JAR signing and he said that your
>understanding of the problem is correct: that the classes that you require
>(i.e. transitive closure minus the JRE's classes) must be in your JAR
>and
>must all be signed by your certificate.
>
>The only other alternative that I know of is to providing the other
>necessary classes in a library JAR and having the user install it into
><jre>/lib/ext. That's pretty bad though.
>
>Peace,
>
>--
>Cameron Purdy
>Tangosol, Inc.
>http://www.tangosol.com
>+1.617.623.5782
>WebLogic Consulting Available
>
>
>"Joe Herbers" <jher...@synchrony.net> wrote in message
>news:3a7ffacf$1...@newsgroups.bea.com...
>> Signing it is part of the battle. We are currently using the Sun tool,
>> jarsigner, which is included with the JDK to sign our 1.3 applet (we
>had
>> been signing a CAB before we switched to the plug-in). We are deploying
>> only in IE (at least for now) so we chose not to use netscape's signing
>> tools. Is there a compelling reason to switch? I think we are signing
>the
>> jar ok, is there some reason the exception below would only occur with
>using
>> jarsigner?
>>
>> The related issue is what to put in the client jar. Any thoughts on
>that
>> are also appreciated.
>>
>>
>> "Cameron Purdy" <cpu...@tangosol.com> wrote in message
>> news:3a7f7213$2...@newsgroups.bea.com...
>> There are some tricks to getting signing to work. We'll be posting
>an
>> article on it soon, but in the mean time I've emailed you a copy.
>>
>>
>> "Joe Herbers" <jher...@synchrony.net> wrote in message
>> news:3a7f1b03$1...@newsgroups.bea.com...
>> > We're having a problem with deploying WebLogic classes for our applet.
>If
>> > we leave the classes on the server in the dir classes/weblogic, then
>the
>> > client can download them ok as needed. However, there are some
>exceptions
>> > that we want to catch when the network is down, for example, so if
>you
>> don't
>> > already the WL classes locally when this happens, the applet fails.
> And
>> > it's more efficient to download all the needed classes in one jar.
>> >
>> > The hard part is knowing what WL classes to include in our jar.
>We see
>an
>> > applets.jar file in the weblogic51\classes directory that looks
>relevant.
>> > But from what I've read on these newsgroups, and the fact that this
>file
>> > does not seem to be updated by the service pack installations (sp8
>for
>> > example), I'm guessing it's not too much use, unfortunately. True?
>> >
>> > We could try running WL's AppletArchiver or just examine the access.log
>> > aftera client runs but this requires us to exercise *every* possible
>> > execution path in our code to make sure we have every class included
>> (which
>> > means things like network disconnect, etc.) [Is there a static class
>> > dependency tool?] We did this in the past and it worked ok since
>the
>> applet
>> > could always fall back to the server and download a class if we missed
>> > something.
>> >
>> > But that was with CABs or unsigned jars. With a *signed* client-side
>jar,
>> > we are getting the following which I imagine is because we have included
>> > some webogic/rjvm classes in our signed jar but not others - when
>it
>> > realizes it needs a class we haven't included (like LocalConMan)
>we get
>> this
>> > exception. Suggestions?? Other people must have this issue...
>> >
>> > Exception: java.lang.SecurityException: class
>> "weblogic.rjvm.LocalConMan"'s
>> > signer information does not match signer information of other classes
>in
>> the
>> > same package
>> >
>> > java.lang.SecurityException: class "weblogic.rjvm.LocalConMan"'s
>signer
>> > information does not match signer information of other classes in
>the
>same
>> > package
>> > at java.lang.ClassLoader.checkCerts(Unknown Source)
>> > at java.lang.ClassLoader.defineClass(Unknown Source)
>> > at java.security.SecureClassLoader.defineClass(Unknown Source)
>> > at sun.applet.AppletClassLoader.findClass(Unknown Source)
>> > at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
>> > at java.lang.ClassLoader.loadClass(Unknown Source)
>> > at sun.applet.AppletClassLoader.loadClass(Unknown Source)
>> > at java.lang.ClassLoader.loadClass(Unknown Source)
>> > at java.lang.ClassLoader.loadClassInternal(Unknown Source)
>> > at weblogic.rjvm.RJVMManager.getLocalRJVM(RJVMManager.java:137)
>> > at weblogic.rjvm.Kernel.ensureInitialized(Kernel.java:130)
>> > at
>> >
>>
>weblogic.common.internal.DNSBasedRJVMFinder.findOrCreate(DNSBasedRJVMFinder.
>> > java:203)
>> > at
>> weblogic.common.internal.ServerURL.findOrCreateRJVM(ServerURL.java:156)
>> > at
>> >
>>
>weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFact
>> > ory.java:266)
>> > at
>> >
>>
>weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFact
>> > ory.java:180)
>> > at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>> > at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>> > at javax.naming.InitialContext.init(Unknown Source)
>> > at javax.naming.InitialContext.<init>(Unknown Source)
>> >
>> >
>> >
>>
>>
>>
>>
>
>
>
>
Abraham Fathman
This same basic problem occurs with WL 5.1.
We just got a fix to WL 5.1 to sp8 - called:
cr042423_rel510sp8.jar.
There is also an outstanding Change Request for 4.5.1, CR 046283.
We have not gotten a fix for that yet.
Just fyi,
Abe