JDK-8038006 : RDF: Security dialog popup while Java <--> JavaScript communication
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u55
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2014-03-20
  • Updated: 2014-07-29
  • Resolved: 2014-04-02
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.
8u20 b09Fixed 9Fixed
Related Reports
Relates :  
Oddly 7u55's reduced warning dialog feature *generally* work quite well, but have 1 applet (well actually 2 on one page) where seem to get the warning dialog every single time.

Not sure why this is occurring and don't have a standalone case.  The applets in question are small but their usage is fairly complex, involving Java <--> JavaScript communication, placement on initially hidden divs, etc.

Not a standalone test program can be provided to duplicate the problem.

Priority justification:
Impact: High, impact cusotmer product
Likelhood: Medium, intermittent.
Workaround: High, No workaround

ILW = HMM => P2 

Unable to verify as the id/pwd provided in bug report do not work.

webrev: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.9.0/8038006/deploy/webrev/ crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-158

in JDK9, with small change to CPCallbackHandler (that is in 7u55) I can see this problem. One applet seems to show first a signed security dialog, then save the decision time, then show an unsigned security dialog, and try to save it's decision time. First problem is that the appHash we use to ensure the app is the same and that has the same args, includes the document base. In this case, the root of the docbase URL is the same but each time it is invoked with different query strings. For this I will look into using HttpUtils.removeWueryStringFromURL. (may need security team input) This handles the first applet, but this is two or three applets, and the next one "wt.security.PrivilegeSetEditor" is run with different applet parameters each time, so we cannot ensure that it is the same applet as defined by the requirements of RDF. This second applet has all-permissions and is properly signed, so user can permanently accept the cert, but the RDF feature will not work on it if the cert is not permanently accepted. part of the change in applet parameters is internal. The plugin itself adds applet parameters: __pluginTemp__pluginWin __pluginTemp__pluginVar __jre_installed __applet_relaunched __applet_launched __jvm_launched __applet_ssv_validated __applet_ssv_version __applet_request_version __ui_tk __jfx_installed __applet_session_data some of these are timestamps, so will change all the time. I am not sure if these are all the parameters that are changing in this app, but seems we can never match parameters if these are all included. Also - there is problem in the way we include the parameters in the appArgs in the AppInfo object, which may be able to be addressed with this fix.

targeting this to 8u20 to keep it on the radar - but may need port earlier release when completed.