1 2 Previous Next 21 Replies Latest reply on Nov 14, 2011 5:48 PM by 899552 Go to original post
      • 15. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29
        In JDK 6u29 a change was made to bring Java into closer alignment with the web Same Origin Policy. In some cases this has caused existing applications to break. The problem manifests when secure cookies are expected to be sent over an insecure connection. If you application depends on this behavior you will need to sign the application. In addition, if the request originates via a LiveConnect (javascript) call then it will need to be wrapped in a doPriviliged() block as javascript calls are treated as untrusted and do not carry the same protection domain.

        I realize that if your application uses just the Microsoft RSProxy class for remote scripting this isn't a likely solution for you. We're still looking at this.

        The following documents contain some relevant information:
        1 person found this helpful
        • 16. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29
          Wrapping the code in our applet called by JavaScript in a doprivileged block fixed our problem. Thank you for your assistance!
          • 17. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29
            Is their any update for the applications that use rsproxy class files? thanks in advance.
            • 18. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29
              I know this isn't a solution to the update 29 problem per se, but we've decided to use another technology for remote scripting, doing away with rsproxy.class. What we're using now is a javascript function:

              function makeHTTPcall(UString)
                   var xmlhttp;
                   if (window.XMLHttpRequest)
                        {// code for IE7+, Firefox, Chrome, Opera, Safari
                             xmlhttp=new XMLHttpRequest();
                        {// code for IE6, IE5
                             xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
                   return xmlhttp.responseText;

              Which gets used like this in the client-side javascript:

                        var URLString = "ServerSideScripts.asp?func=DoTheUpdate&p=" + paramvalue;
                        var retCode = makeHTTPcall(URLString);

              ServerSideScripts is normal (in our case, Classic) ASP code.

              It's working very well for us as a replacement, and will eliminate the need for Java in order to do remote scripting.
              • 19. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29
                SteveW - thanks for the suggestion for folks blocked by rsproxy.

                I wanted to let everyone know that the latest builds of the JRE (to be released in December) have the fix for this problem incorporated. The latest build of 6u30 is at http://jdk6.java.net/6uNea.html.

                The background on this is:

                - We made a change in 6u29 to improve security in regards to the same origin policy (SOP), bringing Java into better alignment with the web standard (while trying not to break existing applications).

                - There is a bug where calls from Javascript (via "LiveConnect") to applets did not carry the same protection domain as the applet. This is what has been corrected in the latest early access builds of JRE 6 and 7. Sorry about that!

                - If (your application is unsigned OR you call a method via Javascript that attempts to access a secure cookie) we now check that the application is served from the same domain via httpS. If not you will still get this error, and that is the expected behavior because it's clearly a violation of the SOP.

                Hope that helps.
                • 20. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29

                  Just to let everyone know 7u2-b11 Developer Preview is also available now. It has also addressed the issue.


                  Please give it a try. Thanks!
                  • 21. Re: Applet altering value of JSESSIONID cookie in Java 6 Update 29
                    Hi, we had a similar issue with our component which seems to be related to the new security changes made by Java 6 in Update 29. We are using the Java's URL Object (HttpClient) on port 80 to connect to the host either for downloading/uploading purposes. The applet is signed and needed permission entries are added in .java.policy configuration file.

                    As mentioned in this discussion, as long as the applet is trying to connect to the same host the applet should be able to connect with the host and should not have any permission issue.

                    I ran three tests on the same host. using Internal-IP (worked fine with no problems), using computer name (worked fine) and using the external DNS (domain name e.g. user.host1234.com) and this always gives a socket permission, I tested the last option both within the network(which resolves to internal ip) as well as connecting from external client machine (which resolved to external ip) in both cases I got the following SocketPermission error!!!

                    java.security.AccessControlException: access denied (java.net.SocketPermission connect,resolve)
                    at java.security.AccessControlContext.checkPermission(Unknown Source)

                    Please advise on how this can be resolved?

                    FYI: I don't exactly know what is happing within Java API's but I am thinking that the Java URL object uses the primitive Java Socket object which tries to resolve the the DNS to ip in order to connect to the host and although we tried to run the applet using url like http://user.host1234.com/applettest.htm some how Java thinks there is a conflict between the resolved and the dns name as if the applet is trying to connect to a different host and therefore flags the socket permission error.

                    FYI: I also tested the same scenarios with the pre-release Update 30 and still have same problems as update 29.

                    Your prompt response is really appreciated.

                    1 2 Previous Next