Applets and 1.7.0_21?

K

Knute Johnson

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,
 
K

Knute Johnson

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?
 
A

Arne Vajhøj

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
 
M

markspace

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.
 
A

Arne Vajhøj

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
 
R

Richard Maher

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 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
 
K

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 :).
 
J

John B. Matthews

Knute Johnson said:
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>
 
K

Knute Johnson

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...
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top