JDK-4774627 : Loading 1.4 plugin from HTTPS page fails for Win2K user with mandatory profile
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.0_01
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-11-06
  • Updated: 2003-01-15
  • Resolved: 2002-11-19
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.
Other Other Other
1.4.0_04 04Fixed 1.4.1_02Fixed 1.4.2Fixed
Related Reports
Relates :  
Relates :  
Description
A customer is running into problems trying to load an applet from an https web page when using the mandatory profiles on Windows 2000 (ntuser.man) instead of the typical profiles (ntuser.dat).   Problem can be reproduced with the following steps:

1.  Create a new profile on a Windows 2000 system and assign it to a mandatory profile according to the directions at http://support.microsoft.com/default.aspx?scid=KB;EN-US;q323368&.  From
that page:

"A mandatory user profile is a user account in which the settings are
preconfigured by the administrator. If you are using a mandatory user profile, you can modify the profile, but when you log off the computer, the changes are not saved to the profile location (the changes are non-persistent). When you log on to the computer again, the original mandatory profile is loaded on the computer."

2.  Install a 1.4.0_xx or 1.4.1_xx plugin on the Windows system.

3.  Point to this page which loads an applet -
https://greenray.east:8443/sbc/example2.html.  

4.  This fails with a null pointer exception in the plugin console (see
plugin trace file below).

Please note:

-  There are no problems with non-SSL web pages (for example, http://greenray.east/8080/sbc/example2.html) with mandatory profiles.  
-  Both SSL and non-SSL work with the standard ntuser.dat profiles on Windows 2000.   
-  This problem does not exist with mandatory profiles on Windows NT.  It is specific to Windows 2000.
-  The problem does not exist with 1.3.1 (tested both 1.3.1_02 and 1.3.1_06).
-  The problem does exist with both 1.4.0_02 and 1.4.1_01.

This looks related to bug 4479378.  That bug was fixed for most cases in merlin-beta2, but it seems that this particular case was not addressed.  



Java(TM) Plug-in: Version 1.4.0_02
Using JRE version 1.4.0_02 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\test.DTSTEST13.000
Proxy Configuration: Manual Configuration
     Proxy:
http=webcache.east:8080,https=webcache.east:8080,ftp=webcache.east:8080,gopher=webcache.east:8080
     Proxy Overrides: <local>


----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system properties
t:   dump thread list
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:130)
        at java.net.URL.getURLStreamHandler(URL.java:1085)
        at java.net.URL.<init>(URL.java:584)
        at java.net.URL.<init>(URL.java:476)
        at java.net.URL.<init>(URL.java:425)
        at sun.plugin.AppletViewer.getDocumentBase(AppletViewer.java:954)
        at sun.plugin.AppletViewer.getCodeBase(AppletViewer.java:1007)
        at sun.plugin.AppletViewer.appletInit(AppletViewer.java:502)
        at sun.plugin.viewer.LifeCycleManager.initAppletPanel(LifeCycleManager.java:133)
        at sun.plugin.viewer.IExplorerPluginObject$Initer.run(IExplorerPluginObject.java:172)
Caused by: java.lang.NullPointerException
        at java.security.MessageDigest.update(MessageDigest.java:277)
        at sun.plugin.security.WSecureRandom.<init>(WSecureRandom.java:45)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
        at java.lang.Class.newInstance0(Class.java:296)
        at java.lang.Class.newInstance(Class.java:249)
        at java.security.Security.doGetImpl(Security.java:1123)
        at java.security.Security.doGetImpl(Security.java:1070)
        at java.security.Security.getImpl(Security.java:1031)
        at java.security.SecureRandom.getInstance(SecureRandom.java:224)
        at java.security.SecureRandom.<init>(SecureRandom.java:135)
        at sun.plugin.services.WIExplorerBrowserService.getSecureRandom(WIExplorerBrowserService.java:96)
        at sun.plugin.net.protocol.https.Handler$1.run(Handler.java:37)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.plugin.net.protocol.https.Handler.<clinit>(Handler.java:33)
        ... 11 more
java.lang.NullPointerException
        at sun.plugin.AppletViewer.getCodeBase(AppletViewer.java:1007)
        at sun.plugin.AppletViewer.appletInit(AppletViewer.java:502)
        at sun.plugin.viewer.LifeCycleManager.initAppletPanel(LifeCycleManager.java:133)
        at sun.plugin.viewer.IExplorerPluginObject$Initer.run(IExplorerPluginObject.java:172)

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_04 1.4.1_02 mantis FIXED IN: 1.4.0_04 1.4.1_02 mantis INTEGRATED IN: 1.4.0_04 1.4.1_02 mantis
14-06-2004

EVALUATION ###@###.### 2002-11-12 This bug is produced in JRE 1.4.1 release, but it has been fixed in Mantis, the latest build. I have asked the people in CTE group to take a look and for update release fix. Dennis Gu
11-06-2004

WORK AROUND Only available workarounds are to regress to 1.3.1, or to use standard user profiles instead of mandatory. Neither of these workarounds are acceptable. 1.4.0 contains other necessary fixes for this application, and the use of mandatory profiles is required.
11-06-2004

SUGGESTED FIX ###@###.### 2002-11-28 The Mantis fix involved removing the Seed Generation code as part of a fix for #4706382. We cannot however do this for 1.4.0 or 1.4.1 The suggested fix for this is to change WSecureRandom() to the following. public WSecureRandom() { System.err.println("In WSecureRandom"); // Generate seed from native OS - use 128 bits byte[] seed = WSeedGenerator.generateSeed(128); SecureRandom random = null; if ( seed != null ) { System.err.println("Seed is not NULL, using Win32 API to generate seed"); try { // Use SHA to hash the seed to make it more random MessageDigest sha = MessageDigest.getInstance("SHA"); sha.update(seed); seed = sha.digest(); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } } else { System.err.println("WSecureRandom: Win32 API failure, defaulting to use Sun provider to generate seed"); provider = new sun.security.provider.Sun(); try { random = SecureRandom.getInstance("SHA1PRNG", provider); seed = random.generateSeed(20); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } } // Create SecureRandom spi for delegation spi = new sun.security.provider.SecureRandom(); // Set seed spi.engineSetSeed(seed); }
11-06-2004