We are clueless about why my client is encountering a Java Security exception in Safari. Could anyone help?
The exception occurs reliably in Safari on Windows. Thi
On Linux it works.
The Add to cart
button executes the function
function saveLayout() {
showSaveMsg();
var status = document.app.buy();
var loc = "http://www.cengraving.com/s/cart";
if (status == 'GOOD') {
window.location = getCartUrl();
} else {
showErrorMsg(status);
}
}
Some remarks:
Is it normal that the local var loc
is defined after the app call and not used anyway?
Also, a try
catch
may help (in Javascript, wrapping the app.buy()
call).
Besides, I did a bit of research on the Net, and some people - having the same error but from a different usage - report a ClassPath
problem. Do you have anything specific that could prevent the relevant JRE to be utilized?
JRE sandbox tries to prevent javascript originated method calls to do harmful things but only thing it does is making programmers life harder.
Best workaround I've found to this is to build a producer & consumer design pattern event queue which implements very loose coupling between javascript originated calls and actual "dirty work".
What really sucks is that a code which runs fine in XP or Win7 may throw exception in Vista.
It's manifesting as a security exception, but the problem is really a bad URL. If you follow the stack, you'll see there is a MalformedURLException.
This is most likely caused by passing a URI somewhere that was expecting a URL. Through the LiveConnect API from the looks of it. I'd guess it's not finding a host name where one is expected, and is trying to connect to a default, probably localhost. That's disallowed bye the SecurityManager hence the SecurityException.
In href's you can use URI (e.g., HREF="/somepath") because the browser resolves that against the URL for the page itself to produce the a full URL (e.g., http://example.com/somepath).
You can do that in Java by using the [appropriate URL constructor][1].
Update: Ah, I misread; I thought that was a single stack trace.
There used to be a bug where liveconnect could access a jar: url and obtain an arbitrary socket connection. The fix for that might be causing an issue with opening url connections from the liveconnect thread. What happens, if in the buy
method, you start a thread to perform the connection?
[1]: http://download.oracle.com/javase/6/docs/api/java/net/URL.html#URL(java.net.URL, java.lang.String)
i had the same problem. And solved this by self signing the applet...
used the following steps and it worked
javac AppletClass.java
jar cvf AppletClass.jar AppletClass.class
keytool -genkey -validity 3650 -keystore pKeyStore -alias keyName
keytool -selfcert -keystore pKeyStore -alias keyName-validity 3650
jarsigner -keystore pKeyStore AppletClass.jar keyName
just answer the questions it will ask and it will do the work
NOTE : i was getting the error for local read/write file
I have the same problem! JavaScript calls a public method of an applet that is embedded in the same document. This should trigger that the applet loads some data from "home", so the connection should be opened to the same domain from where the applet was loaded - which should be allowed also for unsigned applets without further privileges.
I also recognized this security exception only with Safari (5.0.2 for Windows, JRE 1.6.0_22). The same applet in IE and FireFox is doing well.
I also believe that this is a bug in the Java Sandbox of Safari.
EDIT: Using doPrivileged did not help but I found this workaround: If you "decouple" the JavaScript call from the requested execution through a timer event, the execution will no longer be prohibited by the security restriction that Safari puts into the game here. In detail:
One problem that might make things a bit more complicated is that in the actionPerformed context only static variables are accessible. If the JavaScript call contains variables, these must be put by the initially called method into a staic "buffer" variable from which the scheduled event can read the value afterwards.
In my tests only the javax.swing.Timer provided the required decoupling whereas java.util.Timer could not be used for that purpose.
Is this an applet? If it is, you need to sign your applet for it to access a socket, (which seems to be what you are doing...)
See here for more information:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html