JDK-8046211 - why won't fix?

Phil Race philip.race at oracle.com
Fri Jun 20 18:20:30 UTC 2014


Dalibor is correct .. although for some reason all the comments on the bug
are tagged internal only so anyone looking without being logged in as an
Oracle employee sees no reasoning at all.

I'll ping the evaluator to add some public information.


-phil.

On 6/20/2014 5:52 AM, dalibor.topic at oracle.com wrote:
> JNLP is not part of OpenJDK JDK 7u Project. You may want to try Oracle forums instead.
>
> --
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214<tel:+494089091214> | Mobile:+491737185961<tel:+491737185961>
> Oracle Java Platform Group
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Geschäftsführer: Jürgen Kunz
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
>
>> On 20.06.2014, at 14:32, Richard Kettelerij <r.kettelerij at avisi.nl> wrote:
>>
>> Hi,
>>
>> I'm tracking issue JDK-8046211 and noticed today it was resolved as "won't
>> fix" without any comment. I'm curious as to why it was closed?
>>
>> Our situation: We have a Java applet consisting of 4 jar files and a JNLP
>> file. These files are served over HTTPS from a public webserver (no
>> authentication required). The applet contains an up-to-date manifest with
>> all the entries required since the new Java security baseline. The
>> applet/JNLP file is accessed from a web application using Javascript
>> (deployJava.js). All interaction with the applet is through Javascript.
>> The web application itself runs on a different server and is protected
>> using client certificates (2-way SSL) and basic authentication.
>>
>> Now until Java 7u55 everything worked fine. When loading the applet only
>> one popup was displayed asking the user to trust the applet (which is
>> properly signed) and that was all.
>>
>> However since 7u55 (also 7u60) things have changed: the applet loads fine
>> but as soon as we call a method on the applet (though LiveConnect) the Java
>> VM displays a popup asking the user to select a client certificate and
>> thereafter asks the user to authenticate using BasicAuth.
>>
>> Important note: the user doesn't actually has to select a valid certificate
>> or enter any credentials. If the user cancels any of the dialogs the applet
>> continues to function properly. Logging shows the applet is using the same
>> cookie as the browser so authentication against the server isn't actually
>> taking place. Basically the Java VM is prompting for authentication dialogs
>> for no good reason because the user is already authenticated with a browser
>> cookie.
>>
>> Prior to 7u55 we didn't experience this issue (we have users with 7u40,
>> 7u45 and 7u51). Altogether it appears we encountered JDK-8046211, which has
>> the characteristics of a regression issue. If you guys need any logging or
>> additional information I'd be happy to help.
>>
>> Regards,
>> Richard



More information about the jdk7u-dev mailing list