Granting SocketPermission using signed applet

Question

I have had a dream of locally caching a jar file for an applet so that all the code will be on the client machine after the first time the applet was loaded. Basically, I have a very thin applet composed of a jar class loader and a tiny applet which will check for a jar file on the client and download it from the server if it does not exist. These simple classes are in a signed jar file. Basically, this thin applet does the following:
1) Check for the big, app jar file in c:\Temp
2) If it does not exist, open a URL input stream and get the big jar
3) instantiate a jar class loader object on the now local, big jar file
4) load the "main" class
5) use reflection to run its initialization method
6) the application then attempts to open a socket to the server
I get all the way to step 6 and this is where things go bad. As far as I can tell, the "thin" app loader class has permission to do anything it wants since it was downloaded from a signed jar - I haven't tried to do anything I was not able to do with this class. I think the problem arises because the app class came from a non-signed jar file and it appears to have all the typical applet restrictions. I can make URL connections to the local client (since that's where the code was loaded from), but not anywhere else.
I was hoping all classes the "thin", privileged class loaded would inherit these privileges, but obviously the class permissions come from where the class was loaded from. This is a bummer and my guesses for solving this problem are:
1) grant permission to the entry class for the app somehow (I tried something like this by executing the entry method for the app in a AccessController.doPrivieleged block - no luck)
2) sign the app jar and somehow read and accept its certificate so that all classes loaded from this jar are privileged (I am not sure of how to do this)
I am hoping someone might have an elegant solution to this problem as this is really the last step in my caching solution. By the way, the entry app class is not an applet itself if this is useful information to anyone. The "thin" applet is the only applet and just hands control off to the entry method of the main app class in the jar.
TIA!

Answer 1

Signing an applet provides it with the ability to run outside the sandbox. This does not automatically give the applet permission to do anything it wants. The applet must still request the desired permission before actually attempting an operation that requires that permission. Depending on the browser or whether you are relying on the Java plugin, you need to call the necesary security method first. I wrote a signed applet back in May 2000 which also needed socket permission. I don't have access to the code anymore so I cannot recall exactly the classes and methods you need to invoke. If you search the Signed Applets forum for my name, there are several messages that should help you.
For example:
http://forums.java.sun.com/thread.jsp?forum=63&thread=132336