Prevent abuse of a signed applet?

Hi
I am creating an application using HTML, javascript, and a set of java classes.
Communication betwwen the javascript and java is done by an applet, signed with a real certificate.
I would like to prevent someone copying my signed jar, and abusing it.
The classes behind my applet will do (a.o.) local I/O.
The type of abuse I am worried about is e.g. java code from another jar calling public methods on classes in my signed jar, using them to read or write files, and thus abusing my certificate for doing something else than my applet/jar was meant to.
I am looking for advice on how to prevent such things from happening.
Thoughts that already crossed my mind, are:
- making sure only my applet (and as few as possible other classes) has a public constructor
- declaring as much classes as possible (at least the sensitive classes) as final
- avoid non-final public static variables that contain default names of files
If anyone has some more ideas, please post them! I'll be very gratefull!
If you know about a similar question (and answer) in this forum, please let me know, as I have not found it.

harmmeijer,
thanks for the answer, and especially the idea of checking the call stack!
You scared the hell out of me however, by saying:
Your applet would not work at all in jre 1.4.2 signed or policy, when the method is called by javascriptand reading the thread you referenced!
Everything worked fine in jre 1.4.1_2 and earlier. It continued working in 1.4.2_01 in combination with Netscape (v 7.1)
But the combination MSIE (v6.0) with jre v1.4.2_01 did require a minor change:
From my signed applet, I called a .class.getResource(...).getURL()
It didn't work anymore, so I do it know in my applet's init() method, instead of in a stack started by javascript.
All my other I/O (and reflection) still works (thank all gods!), since I do it in a separate thread that I start in my applet's init() method. I hope it keeps working in jre 1.5 :-)
Any other input is very welcome!

Similar Messages

  • Signed applets called from javascript - how/where to load policy file?

    I'm running into some apparently well-known problems with signed applets accessing a client machine's hard drive.
    So, I can get things to work if I place the following two lines in my 'local' JDK installation:
    permission java.io.FilePermission "${user.home}/x.properties", "read,write";
    permission java.util.PropertyPermission "user.home", "read";These let me a) read the user's home directory and b) read/write a file that's located there.
    What I don't want to do is edit the java.policy file, but I'm having problems loading a separate policy file. The app server we run with our product is jetty, and I'm assuming I would be passing in the '-Djava.security.policy=='filename' with the other jetty start-up parameters- is this a correct assumption? And, what path do I give for the file, will I need to put it somewhere in the .war file we distribute, or in the JDK installation on the server? If it's on the server, will client machine's know about these extra rights?
    I'd REALLY appreciate any help I could get on this...
    thanks in advance,
    +0^^

    Maybe you didn't realize but my previous post was sarcastically ment:
    "hello SUN security stop bugging me in writhing this malicious program"
    and
    "hello SUN security, I'm a good boy now trust what I'm doing"
    Are in a practical sense exactly the same.
    SUN should either remove the stack check or the doprivileged. The stack check takes up
    valuable resources for nothing since a malicious program can easily circumvent that.
    Your post about a malicious user abusing your (CA) signed applet to ruine someone's
    system is correct, it would not be difficult. A CA signed applet will not even ask a user to
    trust or not. This is one of the reasons we have the usepolicy in affect, but this cannot be
    used on "grandma's old PC" since it's too complicated for users to do such things.
    YOU seem to be the one to blame, not the hacker! (The user accepted YOUR
    certificate!).Actually you are to blame, because you made software that exposes a vonurability
    other people can take advantage of.
    what you can do before calling the doprivileged private method is check the call stack.
    So your signed applet has a public method checking the callstack, if this lookes OK
    that method will call the private doprivileged method.
    Here is the example
    package t;
    import java.util.Properties;
    import java.applet.Applet;
    public class test extends Applet {
             public test(){
                   startingPrivileged();
             public void startingPrivileged(){
                   System.out.println("this is the stack");
                   try{
                        throw new Exception("get the call stack");
                   }catch(Exception e){
                        StackTraceElement stack[] = e.getStackTrace();
                        for (int i=0; i<stack.length; i++) {
                             System.out.println("file: " + stack.getFileName() + " method: " + stack[i].getMethodName() + " class: " + stack[i].getClassName() + " at " + new Integer(i).toString());
                        // this is a really simple check to see if this method was started from the t. package
                        // a good hacker can just create it's own package named t and take advantage of this method
                        // if this method was started from the same package there is no reason to make this method
                        // public, protected would work.
                        // there must be a better way to check if this method was called by "your" or "trusted" code
                        if(stack[1].getClassName().startsWith("t.")){
                             dosomePrivileged();
              private void dosomePrivileged(){
                   System.out.println("this is the method that does privileged stuff");
         public static void main(String args[]) {
              new test();

  • Signed applet stopped working in 1.4.2_04

    We have a signed applet that accesses the file system. After installing 1.4.2_04 it produces this exception
    java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)
         at java.security.AccessControlContext.checkPermission(Unknown Source)
         at java.security.AccessController.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkExec(Unknown Source)
         at java.lang.Runtime.exec(Unknown Source)
         at java.lang.Runtime.exec(Unknown Source)
         at java.lang.Runtime.exec(Unknown Source)
         at java.lang.Runtime.exec(Unknown Source)
         at edu.nebraska.foundation.applets.AccessApplet.openNewSession(AccessApplet.java:35)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
         at java.lang.reflect.Method.invoke(Unknown Source)
         at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
         at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
         at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
    java.lang.Exception: java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)
         at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
         at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
    .This was working in 1.4.2 and 1.3.1_08. Anyone else have this problem?

    Sorry, copied and pasted the following, hope it helpes.
    The following examples are for a win 2000 machine, for linux
    you have to use alternative paths but I think the commands
    are about the same.
    The SUN jre doesn't care about IE settings, if an applet is signed it will ask the user "do you trust", if
    the user chooses yes or always the applet can do pretty much anything.
    Because anybody can sign an applet so it will pop up the do
    you trust dialog I prevent this dialog from popping up by
    adding the following to the
    C:\Program Files\Java\j2re****\lib\security\java.policy
    under grant { [/b]
    [color red]
    permission java.lang.RuntimePermission "usePolicy";
    [color]
    You now need to set up special permissions for sites that
    need it, signed applets get no special treatment since you
    specified in the java.policy that policy should allways be
    used.
    When your applet needs to do something it normally could
    not do (applet security) [b]and it needs to do this
    when a user clicks on a html button (applet method called
    from javascript), than all the signing and policy settings
    in the world wouldn't work Unless you grant all permission
    to all code.
    This is because the Java Plug-in executes methods with
    applet sandbox security restrictions.
    http://archives.java.sun.com/cgi-bin/wa?A2=ind0404&L=java-security&F=&S=&P=4012
    To solve this you can start a new thread that checks ...
    times a second if a variable meets certain conditions.
    These conditions are changed with public methods called
    from JavaScript. When a variable meets certain Conditions
    this thread will start the method that will perform
    normally restricted tasks.
    Here is an example where the applet doesn't work
    (the batchfile, html file are OK)
    Note that running this code with Mozilla on my w2k machine
    crashes Mozilla (not on my Fedora machine)
    Batch file to sign the applet: (please note this will
    delete some files)
    del *.cer
    del *.com
    del *.jar
    del *.class
    javac -classpath ".;C:\Program Files\Java\j2re1.4.2_04\lib\plugin.jar" test.java
    keytool -genkey -keystore harm.com -keyalg rsa -dname "CN=Harm Meijer, OU=Technology, O=org, L=Amsterdam, ST=, C=NL" -alias harm -validity 3600 -keypass pass -storepass pass
    jar cf0 test.jar test.class
    jarsigner -keystore harm.com -storepass pass -keypass pass -signedjar sTest.jar test.jar harm
    del *.classThe html page:
    <DIV id="dvObjectHolder">  </DIV>
    <br><br>
    <script>
    if(window.navigator.appName.toLowerCase().indexOf("netscape")!=-1){ // set object for Netscape:
         document.getElementById('dvObjectHolder').innerHTML = "        <object ID='appletTest1' classid=\"java:test.class\"" +
                    "height=\"0\" width=\"0\" onError=\"changeObject();\"" +
              ">" +
                    "<param name=\"mayscript\" value=\"Y\">" +
                    "<param name=\"archive\" value=\"sTest.jar\">" +
            "</object>";
    }else if(window.navigator.appName.toLowerCase().indexOf('internet explorer')!=-1){ //set object for IE
         document.getElementById('dvObjectHolder').innerHTML =      "<object ID='appletTest1' classid=\"clsid:8AD9C840-044E-11D1-B3E9-00805F499D93\"" +
                   "         height=\"0\" width=\"0\" >" +
                   "   <param name=\"code\" value=\"test.class\" />" +
                      "<param name=\"archive\" value=\"sTest.jar\">" +
                   " </object>"
    </script>
    <LABEL id="lblOutputText">This text will be replaced by the applet</LABEL>
    <BR>
    <input value="Javascript to java" type=button onClick="document.appletTest1.fromJavaScript()"><br>The applet:
    // new class for jsObject!!!! since 1.4.2 compile this:
    // javac -classpath "C:\Program Files\Java\j2re1.4.2_01\lib\plugin.jar" test.java
    // since jaws.jar does not exsist anymore
    // to compile with jaws: javac -classpath "C:\j2sdk1.4.0_03\jre\lib\jaws.jar" test.java
    import netscape.javascript.*;
    public class test extends java.applet.Applet {
        JSObject win;
        JSObject outputLabel;
        public void init() {
             try{
                 win = JSObject.getWindow(this);
                 outputLabel = (JSObject) win.eval("document.getElementById('lblOutputText')");
              outputLabel.setMember("innerHTML", "<center><h1>From Init<br>Your homedir " + System.getProperty("user.home") + "</h1></center>");
            }catch(Exception e){
                 e.printStackTrace();
        public void fromJavaScript(){
             try{
                     outputLabel.setMember("innerHTML", "<center><h1>From javascript<br>Your homedir: "+ System.getProperty("user.home") + "</h1></center>");
            }catch(Exception e){
                 e.printStackTrace();
    }When you put the files in c:\temp, run the batch file to
    compile and sign the applet and then open the html file you
    will be asked if you trust ... you can say yes and from
    init the applet can read user.home. Click on the button and
    you will get the following stack trace:
    java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
         at java.security.AccessControlContext.checkPermission(Unknown Source)
         at java.security.AccessController.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
         at java.lang.System.getProperty(Unknown Source)
         at test.fromJavaScript(test.java:20)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
         at java.lang.reflect.Method.invoke(Unknown Source)
         at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
         at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
         at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.plugin.com.DispatchImpl.invoke(Unknown Source)Conclusion: the applet can read user.home but not from
    JavaScript.
    Here is the applet that does work because a method called
    from javaScript doesn't perform a restricted task.
    // new class for jsObject!!!! since 1.4.2 compile this:
    // javac -classpath "C:\Program Files\Java\j2re1.4.2_01\lib\plugin.jar" test.java
    // since jaws.jar does not exsist anymore
    // to compile with jaws: javac -classpath "C:\j2sdk1.4.0_03\jre\lib\jaws.jar" test.java
    import netscape.javascript.*;
    public class test extends java.applet.Applet {
         JSObject win;
         JSObject outputLabel;
         boolean buttonFromJavaClicked = false;
         checkJavaScriptEvent evt = new checkJavaScriptEvent();
         public void init() {
              try {
                   evt.start();
                   win = JSObject.getWindow(this);
                   outputLabel =
                        (JSObject) win.eval("document.getElementById('lblOutputText')");
                   outputLabel.setMember(
                        "innerHTML",
                        "<center><h1>From Init<br>Your homedir "
                             + System.getProperty("user.home")
                             + "</h1></center>");
              } catch (Exception e) {
                   e.printStackTrace();
         public void fromJavaScript() {
              buttonFromJavaClicked = true;
         private void fromJavaScript2() {
              System.out.println("fromjavascript2 is started");
              try {
                   String strLbl =
                        "<center><h1>From javascript<br>Your homedir: "
                             + System.getProperty("user.home")
                             + "</h1></center>";
                   outputLabel.setMember("innerHTML", strLbl);
              } catch (Exception e) {
                   e.printStackTrace();
         class checkJavaScriptEvent extends Thread {
              public void run() {
                   while (true) {
                        if (test.this.buttonFromJavaClicked) {
                             System.out.println("OK buttonfromjava is true");
                             test.this.buttonFromJavaClicked = false;
                             test.this.fromJavaScript2();
                        try {
                             Thread.sleep(300);
                        } catch (Exception e) {
                             System.out.println("exception in sleep");
                             e.printStackTrace();
                             System.exit(1);
    }

  • Signed applets (are policy files needed!)

    I have experienced on a number of different machines that a signed applet that the client trusts (via clicking on yes to the prompt asking to trust the applet), is able to access the local resources with NO policy file on the client machine. I'm using JRE 1.4.1_02
    Is this the expected behavior?
    I sure hope it is because how in the world can you install applications to many clients and update their policy file? you can't via the web! BUT why am I reading that you have to have a policy file even if you sign an applet. I want to get rid of using Netscape security model but I can not update many client machine policy files... Please help!!! thanks. Is signing an applet all you have to do to access local machines, I sure hope so! Thanks in advance.

    I've done some more research specifically a very good article at http://developer.java.sun.com/developer/technicalArticles/Security/applets/index.html. I'll try to highlight the more interesting comments that I found. At least for the JRE 1.3 there appears to be a new class loader, sun.plugin.security.PluginClassLoader that allows a signed jar file (once trusted by the client) to have access to local resources.
    Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine.
    Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets.
    There is no simply way to deploy and use customized policy files, a policy will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily.
    Policy files are difficult or at least not very straightforward for normal users, which could be thousands of machines where an applet is deployed.
    The java plug-in (I believe its 1.3 and later) provides a workaround although its recommended to use policy files wherever practical and applicable. (This implies to me that using the plug-in, all that is required is to sign the jar file to have access to local resources).
    RSA-signed applets can be deployed using the Java plug-in. (which can run in an identical way for Netscape and IE).
    In order for a plug-in enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. A NEW CLASS LOADER, sun.plugin.security.PluginClassLoader in the Java Plug-in 1.3, OVERCOMES THE LIMITATIONS MENTIONED ABOVE.
    I hope this helps, I've been looking for this solution for quite some time, trying to understand why singed applets work with no policy files for version 1.4... Talk to you later, Jay.

  • Checking integrity of signed applets in JRE cache

    Hello,
    I noticed that my JRE (Version 6 Update 24) does not check, if a signed applet, that is cached locally, has been modified before loading it. It seems to me like this is a security problem that could easily be prevented. Does anyone know if this is a desired behavior and if there is a way to tell the JRE to check the integrity of cached applets?
    Best regards!

    If any malicious code has sufficient privileges to manipulate the cache of signed applets, then it can easily do much worse things than elevate the privileges of some unsigned Java code.

  • Determine when signed applet certification is rejected

    Hello,
    When a signed applet is first run and the cert is verified, the dialog allows the user to "Run" or "Cancel". If they click "Cancel" the applet continues to run, but without the permissions it may need to do its job. Is there a way for the applet or the web page to determine if the user clicked "Cancel"?
    The applet can of course try to do a privileged operation and catch AccessControlException, but that doesn't necessarily mean that the user clicked "Cancel"; maybe OS or browser security settings are preventing the applet from doing the operation.
    Thanks

    Yes, you can check that a permission is allowed without attempting that action. You will need to change the 'permission' object to be of the type of permission that you want to check.
    try {
    java.util.PropertyPermission permission = new java.util.PropertyPermission("my.fav.property", "read");
    java.security.AccessController.checkPermission(permission);
    System.out.println("Permission Check Passed");
    } catch (AccessControlException e) {
    System.out.println("Permission Check Failed");
    }

  • Signed Applet Duration...

    Hi,
    After signing an applet using jarsigner, it says the cert will expire within 6 months. Is there any way to prevent or extend this or does a new, signed applet have to be provided every 6 months?
    Thanks!
    Matt

    When you generate a keystore with the keytool command you can provide the number of days that this
    store will be valid.
    Using this keystore you can sign the applet:
    http://forum.java.sun.com/thread.jsp?forum=63&thread=524815

  • Signed applet don't work on XP

    Hi,
    I'am currently working on a point-of-sale (POS) using windows XP/Firefox and a linux apache/jboss server.
    I have developed a dynamic windows library in order to use an industrial printer connected to the POS to perform some printing without confirmation of the customer.
    The POS is under Windows XP SP2 and use Firefox 2.0.0.11/JRE 1.5.0.14.
    This dll is used by a signed applet located on the apache/jboss server.
    The applet is correctly downloaded by the client, but normally i have to wait for the certicat authentification windows appearing and for confirming that i want execute the applet. And instead i have a java exception :
    security: La v�rification du certificat � l'aide des certificats AC racine a �chou�
    security: Aucune information d'horodatage disponible
    java.lang.NullPointerException
         at com.sun.deploy.ui.UIFactory.showSecurityDialog(Unknown Source)
         at com.sun.deploy.security.TrustDeciderDialog.showDialog(Unknown Source)
         at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
         at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
         at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
         at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
         at java.security.SecureClassLoader.defineClass(Unknown Source)
         at java.net.URLClassLoader.defineClass(Unknown Source)
         at java.net.URLClassLoader.access$100(Unknown Source)
         at java.net.URLClassLoader$1.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(Unknown Source)
         at sun.applet.AppletClassLoader.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 sun.applet.AppletClassLoader.loadCode(Unknown Source)
         at sun.applet.AppletPanel.createApplet(Unknown Source)
         at sun.plugin.AppletViewer.createApplet(Unknown Source)
         at sun.applet.AppletPanel.runLoader(Unknown Source)
         at sun.applet.AppletPanel.run(Unknown Source)
         at java.lang.Thread.run(Unknown Source)
    security: L'utilisateur a refus� les droits d'acc�s au code
    basic: Taille de cache du chargeur de classes courant : 1
    basic: Termin�...
    basic: Jonction du thread d'applet...
    basic: Destruction de l'applet...
    basic: Elimination de l'applet...
    basic: Sortie de l'applet...
    java.lang.ExceptionInInitializerError
         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
         at java.lang.reflect.Constructor.newInstance(Unknown Source)
         at java.lang.Class.newInstance0(Unknown Source)
         at java.lang.Class.newInstance(Unknown Source)
         at sun.applet.AppletPanel.createApplet(Unknown Source)
         at sun.plugin.AppletViewer.createApplet(Unknown Source)
         at sun.applet.AppletPanel.runLoader(Unknown Source)
         at sun.applet.AppletPanel.run(Unknown Source)
         at java.lang.Thread.run(Unknown Source)
    Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.C:\Program Files\BICImpression\impression_api.dll)
         at java.security.AccessControlContext.checkPermission(Unknown Source)
         at java.security.AccessController.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkLink(Unknown Source)
         at java.lang.Runtime.load0(Unknown Source)
         at java.lang.System.load(Unknown Source)
         at applets.impression.Impression.<clinit>(Impression.java:38)
         ... 11 moreand then the certicat authentification windows appears but it's too late, the applet won't never execute ...
    the apache/jboss server is accessed via some gateway, firewal, ... tha t i can't control
    the apache jboss/server on my own PC is accessed directly :
    What is amazing, is that work fine with my own professionnal PC on W2000 SP4, with JRE1.5.0.14 and Firefox 2.0.0.11 :
    when I look in the java console, the java freeze until i have answered this java security window (certicat authentification windows). And when i answered "run" no problem the applet makes her own job.
    here is the code when it works :
    security: La v�rification du certificat � l'aide des certificats AC racine a �chou�
    security: Aucune information d'horodatage disponible
    basic: Plugin modality.pushed
    basic: Modalit� empil�e
    basic: push javax.swing.JDialog[dialog0,379,296,519x323,layout=java.awt.BorderLayout,modal,title=Avertissement - S�curit�,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,22,513x298,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
    basic: Chargement arr�t�...
    basic: Arr�t de l'applet...Conclusion
    POS : Win XP SP2, JRE1.5.0.14 (i tried 1.5.0.6 and 1.6.3 the latest), Firefox 2.0.0.11 (I tried 2.0.0.0 and 3 beta2 don't work anyway)
    my own server/client : W2000 SP4, JRE1.5.0.14, Firefox 2.0.0.11
    Linux server : RHEL4
    It works with IE on the POS with the linux sever but it's not the selected browser.
    It works with IE on the POS with my own server.
    It works with Firefox on the POS with my own server.
    It works with IE on my own server with the linux sever but it's not the selected browser.
    It works with IE on my own server with my own server.
    It works with Firefox on my own server with the linux sever.
    It works with Firefox on my own server with my own server.
    If you have some idea to make it work i'm you're buyer !!
    Thank a lot for reading this, and i apologize for my poor english ...
    greetings,
    Benoit
    Edited by: bendur on Feb 29, 2008 3:49 AM

    Ok I have found my problem :
    On every web pages, we have defined some inactivity timeouts.
    On my own server I have disabled these timeouts but not on the distant timeout.
    And it seems that the timeout (defined in javascript ont he web pages : 3s) has a very bad influence on the launching of my applet ... only with firefox (with IE and Opera no problem)
    My problem is anwsered but the problem keep alive for firefox ...

  • IIS, Javascript, Signed Applet and ASP Blank Page Problem

    Hi,
    I'm having a problem using a Signed Applet in a site that runs in a IIS (Windows Server 2003).
    My aspx web page uses the applet to read my smart card and get information from it.
    This applet uses an auxiliar dll (stored in a second Signed Jar file) in order to read the information from my smart card.
    The way the solution is design:
    1) Aspx page is asked from server
    2) Internet Explorer recieve the page and asks the server for it content (images, applet, javascripts, etc)
    3) After this the JVM runs (console opens)
    4) After the Aspx page render fully a javascript register onload fires and call an applet method
    5) Applet receive the call and run the logic of the method:
         - reads the smart card;
         - calls Javascript function in order to fill aspx fields with information from smart card
         - calls Javascript function the simulates a click in a botton of aspx page (in order to call server side part sending data readed from smart card to server)
    5) The server makes some logic with the information receive and responds to client registering in aspx page a call to another Javascrit function
    6) The client received the asnwer from server and runs the Javascript function registered on step 5)
         This Javascript calls another method from applet and runs the following logic:
         - reads more information from smart card;
         - call javascript function in order to fill more fields of aspx page with the information readed
         - calls Javascript function the simulates a click in a botton of aspx page (in order to call server side part sending data readed from smart card to server)
    7) The server makes some logic and call another pages with no Applets
    8) Client asks for a second page with the same applet and we start with another logic express on steps 1);2);3),4);5) and then 7).
    This is all ok, until sometimes the server stop responding correcly for requests regarding this two pages with the Applet.
    When this happens the server just responds with a blank page.
         - with fiddler I can seer the request for the aspx page (that uses the applet)
         - but server responds with a blank html page
    The JVM doesn't fire.
    The IIS log don't show errors.
    The eventviewer doesn't show errors.
    The problem is solved with an IIS reset or a Application Pool reset.
    After a while the problem returns.
    This problem occours for other user in another machine, the server just stops responding correcly to request regarding pages with applets, the other pages still continue to work.
    If we disable Java Control Panel->Advanced->Java Plug-in->Enable the next-generation Java Plug-in the problem seend to stop, but we can't force all clients to disable this option right?
    Or there is a way to force the Applet to run with this option disabled?
    As anyone experience similar problem?
    Regards,
    OF

    This is all ok, until sometimes the server stop responding correcly for requests regarding this two pages with the Applet.
    When this happens the server just responds with a blank page.
    - with fiddler I can seer the request for the aspx page (that uses the applet)
    - but server responds with a blank html pageWell, if http requests look identical in case of success and failure (pay attention to cookies, etc) then it has to be something on the server side.
    It could be that server gets into this wrong state because of previous requests made by applet but it is hard to tell.
    I am not clear how old/new plugin can make a difference unless your applets run in the legacy mode (i.e. you are actually trying to reuse SAME instance of the applet when
    it is loaded next time).
    I'd start with
    1) carefully comparing good/bad sessions
    2) checking whether server will serve correct response to another client when it serves "bad" page for current client
    3) add debug statements to aspx - it is scripted page, may be some condition is not met and then it returns blank?
    4) record all http requests in one session until you get to "error" state and then use any http server testing tool to "replay" this set of requests.
    You should be able to get server into the same state without use of applet. Then you can try to tweak set of requests to see what makes a difference.

  • A sign Applet unable to load "oracle.jdbc.OracleDriver" class

    hi,
    i am chiranjit , i am now working in a web based ERP. where i am using a signed applet which unable to load "oracle.jdbc.OracleDriver" class but it easily loading "sun.jdbc.odbc.JdbcOdbcDriver", i am also giving my code:
    import java.sql.*;
    import java.math.*;
    import java.io.*;
    import java.awt.*;
    class JdbcTest extends Applet{
    public static void main (String args[]) throws SQLException {
    // Load Oracle driver
    DriverManager.registerDriver (new oracle.jdbc.OracleDriver());
    // Connect to the local database
    Connection conn =
    DriverManager.getConnection
    ("jdbc:oracle:thin:@192.168.16.7:1521:kris",
    "plsql", "oracle");
    // Query the employee names
    Statement stmt = conn.createStatement ();
    ResultSet rset = stmt.executeQuery ("SELECT FIRST_NAME FROM
    AUTHORS");
    // Print the name out
    while (rset.next ())
    System.out.println (rset.getString (1));
    // Close the result set, statement, and the connection
    rset.close();
    stmt.close();
    conn.close();
    }

    Hint: The sun.jdbc.odbc.JdbcOdbcDriver is available in any JRE distribution. The Oracle driver is not.

  • Signed Applet not loading on Mac OS X if using HTTPS protocol

    Hi All,
    I need to open a trusted applet on Mac OS 10.2. The applet works fine if using HTTP protocol. But if the protocol used is HTTPS the the applet does not loads and "javax.net.ssl.SSLException - untrusted server cert chain" exception comes on the console.
    The error comes for both - Verisign and javakey - signed applet.
    On seaching for possible solution on the net, i came across following link: http://www.macosxhints.com/article.php?story=20020525101202503&query=Workaround+for+secure+Java+applet+problems
    It says that this is Mac's known bug and gives the workaround as:
    1. Access the problematic site with Internet Explorer on Windows. Click on the padlock item and export the certificate to a file.
    2. Copy the certificate to your Mac.
    3. Use the command
    sudo keytool -import -trustcacerts -keystore /Library/Java/Home/lib/security/cacerts -file mycert.cer
    to import the certificate file to your keystore (substitute mycert.cer with the name of the file containing the certificate). The keystore is password protected - the default password is "changeit".
    4. Restart your browser
    But the client cannot be asked to do all this to run the applet.
    Is this problem being solved by Mac in their java implementation or is there any other possible solution?
    Thanx in advance.
    Regards,
    Charu

    I am experiencing the same problem - I notice it does not happen on OS9.2 using IE but appears a problem on all browsers on OSX
    Apple gave me the following reply.....
    Re: Bug ID# 3268633: cannot load applet class under https connection
    Hello Andrew,
    Thank you for bringing this problem to our attention. We have received feedback
    from engineering on your
    reported issue.
    Please know that to get Java to recognize the certificate you will need to do
    one of two things, depending
    on which VM you are using. Since you want it to work with Internet Explorer, we
    will assume Java 1.3.1.
    In Java 1.3.1 you'll need to add the certificate to
    /Library/Java/Home/lib/security/cacerts using
    /usr/bin/keytool to import the certificate into the certificate database.
    In Java 1.4.1 you should be able to just add the certificate to the keychain
    using certtool. For more
    details on how to do this, please refer to the information found at
    <http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/keytool.html>. After
    doing so, if you should require
    further help from Apple in resolving this issue, we recommend that you request
    assistance from Developer
    Technical Support. This must be done by filing a Technical Support Incident.
    So I am supposed to tell every Mac user to do the above am I?!!!

  • OS X 10.5.6, Safari 3.2.1 hangs when second applet loaded is signed applet

    Dear Forum,
    I've been investigating a customer's problem. She is trying to use our
    VoIP applet, but it continuously freezes Safari when the Trust dialog shows.
    A "Force Quit" is necessary.
    I managed to reproduce the problem consistently on
    - PowerMac7 OS X 10.5.6 (Build 9G55)
    - Architecture: ppc
    - Safari 3.2.1 (5525.27.1)
    - JVM 1.5.0_16 from Apple
    The problem is persistent when:
    - the signed applet is loaded as second applet in the browser
    - the signed applet is cached by the JVM
    Our customer uses:
    - Mac Book ProOS X 10.5.6
    - Safari 3.2.1
    - JVM 1.5.0_16 from Apple
    This problem does not occur on:
    - Mac OS X 10.4.11 (Mac Powerbook G4)
    - Safari 3.2.1 (4525.27.1)
    - JVM 1.5.0_16 from Apple
    and not on:
    - MacBook Air, OS X 10.5.6, 1.6 Ghz Intel core 2 duo
    - Safari Version 3.2.1 (5525.27.1)
    - JVM 1.5.0_16 from Apple
    Steps to reproduce the problem:
    Launch Safari.
    In (first) page/tab go to
    http://www.javatester.org/version.html
    (this uses a non signed applet)
    Open a second tab. Here go to:
    http://ukapi.phonefromhere.com/talk/vtop2.xsql?key=01612884242
    This is a signed applet that will ring our office over VoIP.
    Click the "Trust" button (signed by PhoneFromHere).
    As long as this applet isn't cached by the JVM this will work, so
    the first time you will succeed.
    Now Quit Safari (not "just" close all Safari windows, but a "real" quit) and repeat the exercise.
    The second (and next) time this will fail (only if the signed applet is loaded as second, so the order is important)! This keeps failing until I go (back) to the Java Preference window (via Finder) and explicitly delete the cached files.
    The URL will work when loaded first (cached or not).
    Some diagnostics, that might help:
    I configured the Java Preference window to "enable Logging, Tracing and Show applet livecycle exceptions".
    When the applet fails to load (and Safari freezes/hangs), the last few records of the plugin150.log are:
    <message>basic: Loading http://ukapi.phonefromhere.com/talk/lib/pfh.jar from cache
    <message>basic: Reading cached JAR file from JRE 1.5 release
    <message>basic: Certificates for http://ukapi.phonefromhere.com/talk/lib/pfh.jar is read from JAR cache
    <message>security: Loading certificates from Deployment session certificate store
    <message>security: Loaded certificates from Deployment session certificate store
    <message>security: Checking if certificate is in Deployment session certificate store
    (and then nothing)
    whereas when it succeeds to load, as soon as I click the "Trust" button, it's say:
    <message>security: User has granted the priviledges to the code for this session only
    The Report is a bit too long to port, I'll include the same text above when sending it.
    Model: PowerMac7,2, BootROM 5.1.3f0, 2 processors, PowerPC 970 (2.2), 1.8 GHz, 2 GB
    To cut a long story short? Is this a know bug (I couldn't find anything, but you never know)? Does anyone have any ideas how to fix this?
    Thanks, Birgit

    I have the same issue now after downgrading my Flash plugin. I downgraded from 10 to 9 latest because I like using Camino and for some reason Flash 10 doesn't play nice with Camino. But all of a sudden as I use Camino 2b2 for everyday and Safari 3.2 for banking and such, the browser hangs requiring a forced quit when I close it. I've re-installed the browser twice now with all the previous folders, and preferences erased and caches emptied. I even when to re-installing 10.5.6 and it still crashes, it's odd. Maybe 10.5.7 will address this.

  • File read access denied for signed applet

    Hi:
    I have a signed applet with a certificate generated with the keytool. Yet, I keep getting this error:
    java.lang.Exception: java.security.AccessControlException:
        access denied (java.io.FilePermission C:\WINDOWS\system32\aetpkss1.dll read)The error is produced when the method loadKeyStore(pin) below is called.
        private KeyStore ks;
        private Provider provider;
        private static final String providerName    = "PKCS11";
        private static final String providerLibrary = "aetpkss1.dll";
        public void loadKeyStore(String pin) throws IOException,
         CertificateException, KeyStoreException, NoSuchAlgorithmException {
         if (provider == null)
             registerProvider(providerLibrary);
         try {
             ks = KeyStore.getInstance(providerName,provider);
         } catch (Exception e) {
             throw new KeyStoreException("Failed get keystore instance\n"
                             + e.getMessage());
         try {
             ks.load(null, pin.toCharArray());
         } catch (Exception e) {
             throw new KeyStoreException("Failed load keystore\n"
                             + e.getMessage());
        public void registerProvider(String library)
         throws FileNotFoundException, KeyStoreException {
         String fileName;
         if (new File(library).isAbsolute())
             fileName = library;
         else
             fileName = getAbsolutePath(library);
         if (!(new File(fileName).exists()))
             throw new FileNotFoundException("No such file: " + fileName);
         String config = "name = " + providerName + "\n"
             + "library = " + fileName;
         ByteArrayInputStream confStream =
             new ByteArrayInputStream(config.getBytes());
         try {
             provider = new sun.security.pkcs11.SunPKCS11(confStream);
             Security.addProvider(provider);
         } catch (Exception e) {
             throw new KeyStoreException("Can initialize " +
                             "Sun PKCS#11 provider. Reason: " +
                             e.getCause().getMessage());
        private String getAbsolutePath(String lib) throws FileNotFoundException {
         String[] searchPath;
         /* NOTE: This should be modified to suit different versions of   *
          *       Windows and not just Windows XP                         */
         if (System.getProperty("os.name").matches("^(?i)Windows.*")) {
             searchPath = new String[] { "C:\\WINDOWS\\system32" ,
                             "C:\\java" };
         } else {
             searchPath = new String[] { "/usr/local/lib/" };
         for (int i = 0; i < searchPath.length; i++) {
             if ((new File(searchPath[i] + File.separator + lib).exists()))
              return (searchPath[i] + File.separator + lib);
         throw new FileNotFoundException("Library not in search path " + lib);
        }The above code is called by a java script, the class' constructor is empty.
    The error appears not to be caught by my code. I have tried to insert try/catch statements everywhere to figure out where this error is produced.
    The code is write off of the applet for signing with a smart card by Svetlin Nakov - and his applet works!
    I have also made a CLI application that uses the above code and it works perfectly.
    So: Something is wrong either with my certificate, the signing method, signature verification or something completely different. Any hints?
    The certificate I generated with
    keytool -genkey -keystore mystore -alias me
    keytool -seflcert -keystore mystore -alias meI have tired both with and without the selfcert step.
    Thanks! Erik

    The problem has been identified: Placing registerProvider() in the constructor the error no longer occurs, instead an error is produced when the key store is loaded.
    It appears that the javascript code is not trusted and so, even though the applet is signed, access privileges are restricted to those of the java script.
    A solution to this problem is not clear, but possibly, serving the pages from a trusted server, the java script will be trusted, some documentation seem to indicate.

  • Problems with signed Applet for File Download under JRE 1.4 (works with 1.3

    Dear all,
    i encountered a very strange behaviour with JRE 1.4x. A signed applet used for file download worked on all platforms (Windows NT, 2000 and XP wth/wthout SP...) until I installed JRE 1.4.x (1.4.1 or 1.4.2)
    I get an EOFException when downloading binary files (for ASCII it works fine) when trying to readByte() from a DataInputStream. But not immideately, but after x bytes in the while-loop. Security is fine (I know there have been changes to that in jre 1.4, the applet itself can be started an runs with ASCII files for transfer)
    Does anyone know, what has changed in jre1.4.
    As I said, it works fine under jre 1.3.x
    The relevant code is below: byte bt = dis.readByte(); causes the error
    try{
    // Get URL from Server
    URL uFile = new URL(sFilename);
    sThisURLFile = uFile.getFile();
    Integer inte = new Integer(i);
    //open input stream for the file on server
    DataInputStream dis = new DataInputStream(new BufferedInputStream
    (uFile.openConnection().getInputStream()));
    //open output stream for the file on local drive
    String sFilenameOnly = sThisURLFile.substring(sThisURLFile.lastIndexOf('/')+1);
    int iDotPos = sFilenameOnly.lastIndexOf(".");
    String sExt;
    if (iDotPos > 0) {
    sExt= sFilenameOnly.substring(iDotPos);
    } else {
    sExt = "";
    File fileOut = new File(sDownloadDir + sThisURLFile.substring(sThisURLFile.lastIndexOf('/')+1) );
    DataOutputStream dos = new DataOutputStream(new
    BufferedOutputStream(new FileOutputStream(fileOut)));
    //read one byte from input stream, and write that byte to output stream
    long nByte = 0;
    int iCnt = 0;
    iFilesizeDone ++;
    while (nByte < iFilesize){
    String sErrPs = new String();
    try{
    sErrPs = "00";
    byte bt = dis.readByte();
    sErrPs = "01";
    dos.writeByte(bt);
    } catch (EOFException ee)
    System.err.println("internal EOFException: " + ee.getMessage());
    System.out.println("Error Filesize is " nByte " of " iFilesize "---" + sErrPs);
    break;
    nByte++;
    iFilesizeDone ++;
    iCnt ++;
    if(iCnt >= 10240) {
    ShowProgress(nByte, iFilesize, iFilesizeDone, iFilesizeTotal); // repaint does not work during init-procedure
    iCnt = 0;
    line = "Progress: Total: " + ((iFilesizeDone*100)/iFilesizeTotal) + " perc, " + iFilesizeTotal/1024 +" kbytes" ;
    labLine.setText(line);
    //dos.flush(); // improves Client performance (Agent-Call!)
    dis.close();
    dos.close();
    }// End try
    catch (EOFException ee)
    System.err.println("EOFException: " + ee.getMessage()e);
    catch (SecurityException se)
    System.err.println("SecurityException: " + se.getMessage());
    catch (IOException ioe)
    System.err.println("IOException: " + ioe.getMessage());

    perhaps they've changed something with the file blocking.
    btw, you should try to use something like this
    DataInputStream dis = new DataInputStream(is);
    byte[] buffer=new byte[8192];
    int numBytesRead;
    while ( dis.available()>0 ) {
         numBytesRead = dis.read(buffer);
    }               

  • Signed applet for file download?

    Hello folks,
    I have a signed applet through which i can upload multiple files to a servlet. I wish to create another applet or enhance this one to enable it to download multiple files from the server to the client m/c. Any idea, how to go about it?
    I will appreciate your helpful replies.
    Thank you,
    Coreli

    which part? You apparently already know how to sign an applet... and use a file chooser... and create servlets that can take files.... seems you need to do the opposite and use input streams where you used output streams before and vice versa...

Maybe you are looking for