FULL PRODUCT VERSION :
JRE 1.5.0_01 through 1.5.0_07

A DESCRIPTION OF THE PROBLEM :
Using IE browser or Mozilla firefox with a proxy setting pointing to a ISA proxy server on port 8080. The ISA proxy server has either Basic authentication OR, integrated windows authentication enabled. When the applet connection is being made with a secure (SSL) https connection - the connection fails with a security exception. This has been successfully working for our applet for years across all jre's. And works up to the introduction of 1.5.0_01 (yes it still works with 1.5.0).

If we sign the applet it solves the problem, or if we use http instead of https, or if we roll back to 1.4.x o 1.5.0. None of these are valid workarounds as we provide solutions across all types of scenarios. And yes we understand updating the policy file could solve this issue as well but again we cannot require our customer base to have to make changes to use our applet.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using IE browser or Mozilla firefox with a proxy setting pointing to a ISA proxy server on port 8080. The ISA proxy server has either Basic authentication OR, integrated windows authentication enabled. Use https protocol for communcation.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Applet communication to the server should not require a signed applet or a policy file. This is a regression from all other earlier versions of java.
ACTUAL -
Applet communication to the server through the proxy fails.

ERROR MESSAGES/STACK TRACES THAT OCCUR :

This is the exception with tracing enabled:

network: Connecting https://content1.skillsoft.com/contentlib6/Content/scp/en/PlayerStrings.properties with proxy=HTTP @ /10.20.99.254:8080
network: Connecting https://content1.skillsoft.com/skins/default_35bs4ssl_pc/21948.properties with proxy=HTTP @ /10.20.99.254:8080
network: Connecting https://content1.skillsoft.com/skins/default_35bs4ssl_pc/courseinfo.properties with proxy=HTTP @ /10.20.99.254:8080
java.security.AccessControlException: access denied (java.net.SocketPermission QAPROXY:8080 connect,resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.proxiedConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.doTunneling(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
at java.net.URL.openStream(Unknown Source)
at com.skillsoft.shared.player.SecurityManager.f(Unknown Source)
at com.skillsoft.shared.player.PlayerContext.cb(Unknown Source)
at com.skillsoft.shared.player.PlayerContext.d(Unknown Source)
at com.skillsoft.shared.player.PlayerContext.b(Unknown Source)
at com.skillsoft.legacy.player.PlayerAppletContext.b(Unknown Source)
at com.skillsoft.legacy.player.PlayerAppletContext.<init>(Unknown Source)
at com.skillsoft.legacy.player.PlayerAppletContext.a(Unknown Source)
at com.skillsoft.legacy.player.PagePlayer.init(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I can provide a launch site with the issue if necessary.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Signing the applet, creating a policy file, using http (instead of https) or rolling back to 1.5.0 or 1.4.2.x all solves the problem but are not acceptable workarounds for a commercial applet.

Release Regression From : 5.0
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.