JDK-6647956 : Browser authenticator not working correctly in new Java Plug-In
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-01-08
  • Updated: 2010-09-08
  • Resolved: 2008-01-28
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.
JDK 6
6u10 b11Fixed
Related Reports
Relates :  
Description
The attached test case indicates that the browser authenticator support in the new Java Plug-In is not working correctly. The behavior should be that if the user authenticates to password-protected content using the browser, and then attempts to access the same content via an applet, that the applet should pick up the authentication result from the browser and not prompt the user with an authentication dialog. The behavior observed at least with IE 7 and the new Java Plug-In is that the authentication dialog is presented the first time the password-protected content is accessed from Java even though the user has already authenticated to the browser. This is a regression compared to the old Java Plug-In.

Additionally, at least in IE 7, if "Cancel" is selected in the Java-side authentication dialog, then subsequent attempts to access the content appear to deadlock, apparently due to the pending request not being cleared by the com.sun.deploy.security.DeployAuthenticator.openDialog() method. This is the stack trace for the latter failure:

"thread applet-AuthApplet-2" prio=4 tid=0x0b3dd800 nid=0x3a8 in Object.wait() [0x0bbcf000..0x0bbcfb94]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x03054848> (a java.util.HashMap)
	at java.lang.Object.wait(Object.java:485)
	at sun.net.www.protocol.http.AuthenticationInfo.requestIsInProgress(AuthenticationInfo.java:117)
	- locked <0x03054848> (a java.util.HashMap)
	at sun.net.www.protocol.http.AuthenticationInfo.getServerAuth(AuthenticationInfo.java:258)
	at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:1640)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1087)
	- locked <0x02a12cf8> (a sun.net.www.protocol.http.HttpURLConnection)
	at AuthApplet.start(AuthApplet.java:20)
	at sun.plugin2.applet.Applet2Manager$AppletExecutionRunnable.run(Applet2Manager.java:1508)
	at java.lang.Thread.run(Thread.java:619)

Note that in order to run the attached test case the content must be served up from an Apache web server with mod_auth enabled and with AllowOverride set to "All" (or a sufficient value) in httpd.conf. Additionally, the authtest/protected/.htaccess file's AuthUserFile needs to be modified to point to the location of the test case's .htpasswd file as unzipped on to the web server.
The deadlock above is reproducible with both the old and new Java Plug-In.
The deadlock above is a separate issue from the browser authenticator not working in the new Java Plug-In and has been filed as 6648001.

Comments
EVALUATION The browser authenticator was not functioning in the new Java Plug-In because of a simple and embarrassing backwards null check, causing the functionality to always be disabled. Because no tests have been run against this functionality, this problem was not discovered until now. Thanks to Jess Holle from PTC (a CAP member) for pointing out the regression and for the description of how to write a test case for this functionality. There were additionally a few problems with the new code in the Firefox plug-in for the browser authenticator. The contract ID was not correct for the nsIJVMAuthTools. The assert statements in MozPluginInstance.cpp were never firing, even in debug builds. The string concatenation of the username and password had an off-by-one bug where the password was being truncated. On Windows, it is necessary to use the MSCredentialManager to prevent the authentication dialog from being popped up even after the authentication information is obtained from the browser.
09-01-2008

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6647956.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6647956
09-01-2008