JDK-8035449 : security prompt is shown twice when 'Do not show' checkbox is checked
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u55,8u5
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2014-02-20
  • Updated: 2015-03-04
  • Resolved: 2014-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u65Fixed 8u11 b01Fixed
J2SE Version (please include all output from java -version flag):
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b08)
Java HotSpot(TM) Client VM (build 24.55-b01, mixed mode, sharing)
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b07)
Java HotSpot(TM) Client VM (build 25.5-b01, mixed mode)

Does this problem occur on J2SE 7ux?  Yes / No (pick one)

Operating System Configuration Information (be specific):
Windows 7 (32/64bit), Ubuntu 12.04 (32bit) and Ubuntu 13.20 (64bit). But appears to be a global issue.

Hardware Configuration Information (be specific):
Virtual machines

Bug Description:
We have observed that the java security prompt is shown twice, if the checkbox "Do not show this again for apps from the publisher and location above" is checked. 
If the checkbox is not marked the message is only shown once.

In our setup we have one central server hosting a login applet (server A), and many service providers each with their own server hosting the actual websites (servers B, C, D ...).

Server B (and C, D, E, ...) presents the applet from server A to the end user (client).

Our manifest attributes look like this:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.)
Trusted-Only: true
Sealed: true
Built-By: Administrator
Target-Environment: prod
Caller-Allowable-Codebase: *
Application-Library-Allowable-Codebase: *
Vendor: DanID
Title: Digital Signatur
Version: 1.0
Build: DEVELOPMENT BUILD 2013-10-29 12.17.23
Permissions: all-permissions
Codebase: *
Application-Name: NemID

We do not see the problem when loading the signed applet from https://www.java.com/en/download/installed.jsp.

Steps to Reproduce (be specific):
Prerequisites: Access to a signed applet on a setup where the applet is hosted on an other webserver then the webpage including the applet (for example: https://www.nemid.nu/dk-da/#log_paa_selvbetjening).
1) The signed applet used in this test should not have been accepted with "Do not show this again" checked on the acceptance screen previously.
2) Load the signed applet. The acceptance of signed applet screen is shown.
3) Check the checkbox "Do not show this again". 
4) Press "Run".
5) The acceptance of signed applet screen is shown again.

Priority justification:
ILW = MMM => P3

Verified with 8u11b11 in original test case.

See a test case for verification attached to the crucible review above.

Crucible review is at https://java.se.oracle.com/code/cru/CR-JDK8UCPU-72

SQE OK to defer this fix to CPU14_03

Deferral request justification: We are out of time now, It affects the cases when a distributed application doesn't use JNLP (uses applet tag instead) and codebase and jar location have different domains. It could be that some large customers use such configuration. The workaround is to use JNLP descriptor to deploy such application.

I reproduced the issue, The fix for 8034794 doesn't solve the problem. Codesource:(https://applet.danid.dk/bootapplet/1393017139344 ) Codebase:(https://www.nemid.nu/lbox/log_paa_selvbetjening/client)

The application they give above reproduces it: https://www.nemid.nu/dk-da/#log_paa_selvbetjening but seems to be fixed by fix to 8034794

We need a test case to reproduce it. It could be the vulnerability case fixed in JDK-8026725 (an applet doesn't have a 'codebase' attribute and has an absolute URL in the @ archive attribute) , if so than dialogs should show different locations. Please provide the link to the application so we could check it.

possible this is just a direct duplicate of 8034794

seems to be caused by change in AppInfo.getFrom() sometimes returning host of the jar (setFrom called by Plugin2ClassLoader.getAppInfo), and later has codebase of applet (setFrom called by Plugin2Manager.getAppInfo()). If cert is saved in permanent store with string from TrustDecider.getLocString() constructed from one AppInfo, it will not match the other.