Applets and 1.7.0_21?

Discussion in 'Java' started by Knute Johnson, May 21, 2013.

  1. I've got some software running in the wild that uses JApplets. My
    client decided to update the Java version from 1.6 something to
    1.7.0_21. The applets communicate with the server they come from. This
    caused a security exception. I re-compiled and self-signed one of the
    applets to see if that would solve the issue but then I got a
    ConnectException. I'm not sure why and it could be related to the
    Serialzed data being transmitted between the applet and server.

    Should self signing the .jar files solve any problems from changing the
    Java versions for my applets?

    Thanks,

    --

    Knute Johnson
    Knute Johnson, May 21, 2013
    #1
    1. Advertising

  2. On 5/21/2013 8:45 AM, Knute Johnson wrote:
    > I've got some software running in the wild that uses JApplets. My
    > client decided to update the Java version from 1.6 something to
    > 1.7.0_21. The applets communicate with the server they come from. This
    > caused a security exception. I re-compiled and self-signed one of the
    > applets to see if that would solve the issue but then I got a
    > ConnectException. I'm not sure why and it could be related to the
    > Serialzed data being transmitted between the applet and server.
    >
    > Should self signing the .jar files solve any problems from changing the
    > Java versions for my applets?
    >
    > Thanks,
    >


    I just found this on the Oracle site;

    "Changes to Java Control Panel's Security Settings

    In this release, low and custom settings are removed from the Java
    Control Panel(JCP)'s Security Slider.

    Depending on the security level set in the Java Control Panel and the
    user's version of the JRE, self-signed or unsigned applications might
    not be allowed to run. The default setting of High permits all but local
    applets to run on a secure JRE. If the user is running an insecure JRE,
    only applications that are signed with a certificate issued by a
    recognized certificate authority are allowed to run."

    What do they mean by a secure JRE?

    --

    Knute Johnson
    Knute Johnson, May 21, 2013
    #2
    1. Advertising

  3. Knute Johnson

    Arne Vajhøj Guest

    On 5/21/2013 11:58 AM, Knute Johnson wrote:
    > On 5/21/2013 8:45 AM, Knute Johnson wrote:
    >> I've got some software running in the wild that uses JApplets. My
    >> client decided to update the Java version from 1.6 something to
    >> 1.7.0_21. The applets communicate with the server they come from. This
    >> caused a security exception. I re-compiled and self-signed one of the
    >> applets to see if that would solve the issue but then I got a
    >> ConnectException. I'm not sure why and it could be related to the
    >> Serialzed data being transmitted between the applet and server.
    >>
    >> Should self signing the .jar files solve any problems from changing the
    >> Java versions for my applets?

    >
    > I just found this on the Oracle site;
    >
    > "Changes to Java Control Panel's Security Settings
    >
    > In this release, low and custom settings are removed from the Java
    > Control Panel(JCP)'s Security Slider.
    >
    > Depending on the security level set in the Java Control Panel and the
    > user's version of the JRE, self-signed or unsigned applications might
    > not be allowed to run. The default setting of High permits all but local
    > applets to run on a secure JRE. If the user is running an insecure JRE,
    > only applications that are signed with a certificate issued by a
    > recognized certificate authority are allowed to run."
    >
    > What do they mean by a secure JRE?


    I think they mean:

    insecure = old with known vulnerabilities

    secure = no known vulnerabilities

    And with recent history secure approx. means latest.

    Arne
    Arne Vajhøj, May 21, 2013
    #3
  4. Knute Johnson

    markspace Guest

    On 5/21/2013 9:15 AM, Arne Vajhøj wrote:

    > insecure = old with known vulnerabilities
    >
    > secure = no known vulnerabilities



    I haven't read it but I'd guess that "secure" might also refer to a
    sandboxed app, one run with a defined set of security restrictions.
    markspace, May 21, 2013
    #4
  5. Knute Johnson

    Arne Vajhøj Guest

    On 5/21/2013 1:09 PM, markspace wrote:
    > On 5/21/2013 9:15 AM, Arne Vajhøj wrote:
    >> insecure = old with known vulnerabilities
    >>
    >> secure = no known vulnerabilities

    >
    >
    > I haven't read it but I'd guess that "secure" might also refer to a
    > sandboxed app, one run with a defined set of security restrictions.


    That is the normal distinction.

    But in this context I doubt it is the case.

    Arne
    Arne Vajhøj, May 21, 2013
    #5
  6. On May 21, 11:45 pm, Knute Johnson <> wrote:
    > I've got some software running in the wild that uses JApplets.  My
    > client decided to update the Java version from 1.6 something to
    > 1.7.0_21.  The applets communicate with the server they come from.  This
    > caused a security exception.  I re-compiled and self-signed one of the
    > applets to see if that would solve the issue but then I got a
    > ConnectException.  I'm not sure why and it could be related to the
    > Serialzed data being transmitted between the applet and server.
    >
    > Should self signing the .jar files solve any problems from changing the
    > Java versions for my applets?
    >
    > Thanks,
    >
    > --
    >
    > Knute Johnson


    I have an unsigned applet that talks back to the codebase through
    sockets and does not have any problems.

    Were you signed or unsigned before or a mix?

    Does this help:-
    http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

    Cheers Richard Maher
    Richard Maher, May 22, 2013
    #6
  7. On 5/21/2013 5:39 PM, Richard Maher wrote:
    > On May 21, 11:45 pm, Knute Johnson <> wrote:
    >> I've got some software running in the wild that uses JApplets. My
    >> client decided to update the Java version from 1.6 something to
    >> 1.7.0_21. The applets communicate with the server they come from. This
    >> caused a security exception. I re-compiled and self-signed one of the
    >> applets to see if that would solve the issue but then I got a
    >> ConnectException. I'm not sure why and it could be related to the
    >> Serialzed data being transmitted between the applet and server.
    >>
    >> Should self signing the .jar files solve any problems from changing the
    >> Java versions for my applets?
    >>
    >> Thanks,
    >>
    >> --
    >>
    >> Knute Johnson

    >
    > I have an unsigned applet that talks back to the codebase through
    > sockets and does not have any problems.
    >
    > Were you signed or unsigned before or a mix?
    >
    > Does this help:-
    > http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html
    >
    > Cheers Richard Maher
    >


    The applets were running unsigned. I just tried to see if I could solve
    the problems by signing one. It wasn't that successful.

    I think what we are going to do is to convert their code to an
    application. That's what I wanted to do from the get go but they were
    convinced that this would be less hassle. I'm not sure they are
    convinced any more :).

    --

    Knute Johnson
    Knute Johnson, May 22, 2013
    #7
  8. In article <knh41p$akt$>,
    Knute Johnson <> wrote:

    > I think what we are going to do is to convert their code to an
    > application. That's what I wanted to do from the get go but they
    > were convinced that this would be less hassle. I'm not sure they
    > are convinced any more :).


    You may be able to preserve your options by moving toward a hybrid
    applet/application deployed via Java Web Start; some related
    examples are cited here:

    <http://stackoverflow.com/q/12449889/230513>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, May 22, 2013
    #8
  9. On 5/22/2013 11:43, John B. Matthews wrote:
    > In article <knh41p$akt$>,
    > Knute Johnson <> wrote:
    >
    >> I think what we are going to do is to convert their code to an
    >> application. That's what I wanted to do from the get go but they
    >> were convinced that this would be less hassle. I'm not sure they
    >> are convinced any more :).

    >
    > You may be able to preserve your options by moving toward a hybrid
    > applet/application deployed via Java Web Start; some related
    > examples are cited here:
    >
    > <http://stackoverflow.com/q/12449889/230513>
    >


    Thanks for that article John. The whole project was a series of four
    JApplets and some HTML code. I've converted the applets to JFrame
    applications which really only required minor changes to the code.
    Mostly finding all the AppletContext calls to reload the browser and
    replacing them with JFrame.dispose(). Then I wrote a menu application
    that calls those apps and some Desktop.browser calls for the remaining
    HTML that they needed access to. It is a little cludgy but no more so
    than the applets were to begin with. It actually gives them slightly
    more utility as they can have all four applications open at once in
    separate JFrames.

    I don't think running them as Java Web Start applications will work any
    differently with the new security requirements than the applets did.
    It's also not clear to me that self-signing is going to be adequate either.

    I did find one interesting bug in some old code where I didn't dispose
    of the Dialog that was used with a JFileChooser. It was preventing one
    of the apps from stopping completely. The only reason that I can think
    of that that didn't cause them problems before was that they didn't run
    that piece of code very often (so no out of memory error) and it was
    hidden by the browser.

    Thanks,

    knute...
    Knute Johnson, May 23, 2013
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roedy Green

    JDK 1.5.0_21 released

    Roedy Green, Sep 8, 2009, in forum: Java
    Replies:
    6
    Views:
    1,560
    Mike Amling
    Sep 14, 2009
  2. Roedy Green

    JDK 1.6.0_21 released

    Roedy Green, Jul 8, 2010, in forum: Java
    Replies:
    0
    Views:
    7,374
    Roedy Green
    Jul 8, 2010
  3. Roedy Green

    JDK 1.7.0_21 and JDK 1.6.0_45

    Roedy Green, Apr 16, 2013, in forum: Java
    Replies:
    3
    Views:
    419
    Arne Vajhøj
    Apr 17, 2013
  4. Roedy Green

    exec problem is JDK 1.7.0_21

    Roedy Green, Apr 16, 2013, in forum: Java
    Replies:
    66
    Views:
    1,888
    Arne Vajhøj
    Apr 28, 2013
  5. Roedy Green

    Yet another bug in 1.7.0_21

    Roedy Green, Apr 17, 2013, in forum: Java
    Replies:
    4
    Views:
    298
    Roedy Green
    Apr 18, 2013
Loading...

Share This Page