Opening an http connection when in a javascript to java call throws security exception. The origin of the connection is the same server where the applet comes from. Here is the full stack trace. java.security.AccessControlException: access denied (java.net.SocketPermission 192.168.0.17:80 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.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.<init>(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at detectVM.greadC(detectVM.java:329) at detectVM.loginCheck(detectVM.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.plugin.javascript.JSInvoke.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source) at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
the Java plugin used is Java 6u10 beta
Can you please provide the URL of an example that works correctly in other browsers but does not work correctly in WebKit? Does it work correctly in Safari without a nightly WebKit build? Also, what platform are you running on? The OS field indicates you are using Leopard but the Hardware field says you're not using a Mac which seems inconsistent.
This weekend we will put a new release of our product which uses live connect to our web site. I will email a userid/password to you once it is deployed. I believe it will help you all a lot for tunning the performance and stability of Java live connect on Safari. Our initial test was on Safari for Windows. We have not yet tested a nightly WebKit. Are there any live connect improvements since Safari 3.1 at WebKit.
I don't know that there have been any changes since Safari 3.1 -- I asked because the Version field indicated that you were using a nightly build of WebKit rather than a released version, so I was wondering if that was an important factor in the bug report. In the future it would be great if you could select accurate OS and Version values -- the implementation of Java support differs from platform to platform so it's important to make sure we're looking in the right place. Have you had an opportunity to test on Mac OS X at all?
*** Bug 18742 has been marked as a duplicate of this bug. ***
We have not yet tested on Mac OS X, but we used various Java plugins from 1.4.2 to the latest 1.6 beta build22. They all have the same problem. the interesting part is that, I am sure if this is because of a nightly we had installed on top of Safari 3.1. I will check up on that. On the other hand, on windows 2000 using Safari 3.0, everything works fine although windows 2000 is not listed as the prefered setup for Safari to run by Apple.
I have just uninstalled and reinstalled latest Safari 3.1 on Windows XP and problem is there. So it is not a nightly webkit build.
I have uninstalled Safari 3.1 and installed Safari 3.0 on XP that we used with Windows 2000. We get the same error. I am adding the following which was also reported on the duplicate bug. I will now install lastest nightly WebKit build and see. java.security.AccessControlException: access denied (java.net.SocketPermission 192.168.0.17 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.plugin.security.ActivatorSecurityManager.checkConnect(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at com.neurodna.manager.NSendReceiveImp.streamPrivate(NSendReceiveImp.java:653) at com.neurodna.manager.NSendReceiveImp.access$200(NSendReceiveImp.java:95) at com.neurodna.manager.NSendReceiveImp$DefaultReceiver.runURLRequest(NSendReceiveImp.java:182) at com.neurodna.manager.NSendReceiveImp$DefaultReceiver.run(NSendReceiveImp.java:207)
Latest webkit build has the exact same problem.
Created attachment 20945 [details] Test case for the problem Sorry for the test case delay. We havent got the go for product demo so I am attaching a testcase.
The problem only occurs when the applet is delivered from a remote server. It works fine when the applet is delivered from a locally running web server. The reason it was working fine on Windows 2000, because we were running the web server locally. We also always use IP numbers for the servers to access even from remote servers for security reasons. I was wondering if a plain IP address is tagged as insucure by the Safari sandbox.
I have put the test case to our site, you may test it from there and confirm this bug. http://www.neurodna.com/test/LiveConnectTest.htm
since this was left unconfirmed and we have found a different way to implement that part of our code. I am marking this works for me.
All I saw when loading the test case was: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:163) at java.lang.ClassLoader.loadClass(ClassLoader.java:316) at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:119) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:591) at sun.applet.AppletPanel.createApplet(AppletPanel.java:723) at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1870) at sun.applet.AppletPanel.runLoader(AppletPanel.java:652) at sun.applet.AppletPanel.run(AppletPanel.java:326) at java.lang.Thread.run(Thread.java:613) logged to the system console and: Value undefined (result of expression document.getElementById("a").tryToFlood) is not object. http://www.neurodna.com/test/LiveConnectTest.htm (line 11) in the inspector console.
The bug was filed for Windows XP, and the test case was compiled with JRE 6.0. For Mac, If there is Java 6.0 for MacOSX, you may need to install that.