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)
- locked <0x03054848> (a java.util.HashMap)
- locked <0x02a12cf8> (a sun.net.www.protocol.http.HttpURLConnection)
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.