Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24151 > unrolled thread

Applets and 1.7.0_21?

Back to article view | Back to comp.lang.java.programmer

Contents

  Applets and 1.7.0_21? Knute Johnson <nospam@knutejohnson.com> - 2013-05-21 08:45 -0700
    Re: Applets and 1.7.0_21? Knute Johnson <nospam@knutejohnson.com> - 2013-05-21 08:58 -0700
      Re: Applets and 1.7.0_21? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-21 12:15 -0400
        Re: Applets and 1.7.0_21? markspace <markspace@nospam.nospam> - 2013-05-21 10:09 -0700
          Re: Applets and 1.7.0_21? Arne Vajhøj <arne@vajhoej.dk> - 2013-05-21 13:15 -0400
    Re: Applets and 1.7.0_21? Richard Maher <maherrj@googlemail.com> - 2013-05-21 17:39 -0700
      Re: Applets and 1.7.0_21? Knute Johnson <nospam@knutejohnson.com> - 2013-05-21 17:42 -0700
        Re: Applets and 1.7.0_21? "John B. Matthews" <nospam@nospam.invalid> - 2013-05-22 14:43 -0400
          Re: Applets and 1.7.0_21? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2013-05-23 14:17 -0700
    Re: Applets and 1.7.0_21? "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-05-22 20:31 +1000

#24151 — Applets and 1.7.0_21?

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

[toc] | [next] | [standalone]

#24152

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

[toc] | [prev] | [next] | [standalone]

#24153

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

[toc] | [prev] | [next] | [standalone]

#24154

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.

[toc] | [prev] | [next] | [standalone]

#24155

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

[toc] | [prev] | [next] | [standalone]

#24161

On May 21, 11:45 pm, Knute Johnson <nos...@knutejohnson.com> 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

[toc] | [prev] | [next] | [standalone]

#24162

On 5/21/2013 5:39 PM, Richard Maher wrote:
> On May 21, 11:45 pm, Knute Johnson <nos...@knutejohnson.com> 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

[toc] | [prev] | [next] | [standalone]

#24171

In article <knh41p$akt$1@dont-email.me>,
 Knute Johnson <nospam@knutejohnson.com> 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>

[toc] | [prev] | [next] | [standalone]

#24175

On 5/22/2013 11:43, John B. Matthews wrote:
> In article <knh41p$akt$1@dont-email.me>,
>   Knute Johnson <nospam@knutejohnson.com> 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...

[toc] | [prev] | [next] | [standalone]

#24168

"Knute Johnson"  wrote in message news:kng4jh$pcm$1@dont-email.me...

Reply at the end...

-------------------------
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 know of some applets and Web Start apps that either will not launch at all 
or have serious problems since upgrading to 7u21.  In many of these cases 
there is no obvious way to get things to work again and certainly signing is 
not the solution.

It appears Oracle did not properly consider all the possible implications of 
the new "secure" plugin on production apps/applets and do not always have an 
effective work-around.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web