SecurityExceptionEx exception running a Java applet (175622)
The information in this article applies to:
- Microsoft SDK for Java 2.0
- Microsoft SDK for Java 4.0
- Microsoft SDK for Java 2.01
- Microsoft SDK for Java 2.02
- Microsoft SDK for Java 3.0
- Microsoft SDK for Java 3.1
- Microsoft SDK for Java 3.2
- Microsoft Internet Explorer (Programming) 4.0
- Microsoft Internet Explorer (Programming) 4.01
- Microsoft Internet Explorer (Programming) 5
- Microsoft Internet Explorer (Programming) 5.01
- Microsoft virtual machine
This article was previously published under Q175622 SYMPTOMS
When running a Java applet, the security manager throws one of the
following exceptions:
com.ms.security.SecurityExceptionEx[classname.methodname]
com.ms.security.SecurityExceptionEx[Host]
com.ms.security.SecurityExceptionEx[Unknown]
java.lang.SecurityException: J/Direct method has not been authorized for use on behalf of an untrusted caller.
CAUSE- A SecurityExceptionEx[methodname.classname] will occur if your
applet attempts to perform a trusted operation and is not trusted.
- A SecurityExceptionEx[Host] will occur if:
- The Web browser invoked a method that performs a trusted operation and that method did not first assert its permission to perform the trusted operation. This situation will occur if your applet performs trusted operations in the applet's default constructor, init(), start(), stop(), or destroy() method without first asserting its permission.
- The Web browser tries to invoke archive files from the archives, cabbase, or cabinets parameters that are not located relative to the codebase URL. This situation can happen if the applet is being run from one codebase location and the archive files are located in another location different from that of the codebase.
- A SecurityExceptionEx[Unknown] will occur if the script engine invoked a
method that performs a trusted operation, and that method did not first
assert its permission to perform the trusted operation. This situation
will occur if your applet has a public method called by VBScript or
JScript, and that method performs trusted operations without first
asserting its permissions.
- A "java.lang.SecurityException: J/Direct method has not been authorized
for use on behalf of an untrusted caller" will occur if the Web browser
or script engine invoked a method that makes a J/Direct call, and that
method did not first assert its permission to perform the trusted
operation.
RESOLUTION
If a SecurityExceptionEx[methodname.classname] occurs, you must sign your
applet to enable it to perform operations outside of the Java sandbox. For more information, see the documentation in the Microsoft SDK for Java as noted in the "References" section of this article. ( NOTE: You must sign your cabinet file with the appropriate
permissions. -Low or -LowX permission will guarantee you have appropriate
access or you may sign with the appropriate granular permissions using an
ini file passed to Signcode.exe).
If a SecurityExceptionEx[Host] occurs, you can do one of the following:
- If you are sure your caller cannot do harm if your trusted operation is performed, the resolutions are the same as for the SecurityExceptionEx[Unknown] (see paragraph following this bulleted list).
- Ensure that any archive files being referenced in either the archives, cabbase, or cabinets parameter tags are located relative to the codebase for the applet.
If a SecurityExceptionEx[Host], SecurityExceptionEx[Unknown], or
"java.lang.SecurityException: J/Direct method has not been authorized for
use on behalf of an untrusted caller" and you are sure your caller cannot
do harm if your trusted operation is performed, you can do one of the
following:
- Assert your permission using the PolicyEngine class. (NOTE: The lifetime
of PolicyEngine.assertPermission() is the same as the lifetime of the
method in which it is called. Once the method that asserts its
permission returns , you would need to re-assert permissions as needed.)
- Spawn a separate thread to perform the trusted operation, giving
the thread permission to perform the operation.
STATUS
This behavior is by design.
MORE INFORMATION
In the Microsoft virtual machine (Microsoft VM) (build 2252 or later) that is included in the SDK for Java and Internet Explorer 4.0 and
later, the security manager now crawls the call stack when an applet is run
from a signed cabinet file. This behavior is new in this build of the Microsoft VM,
and helps ensure that the applet author is aware of the security risks of
untrusted code manipulating their applet. By asserting an applet's
permission, the programmer is acknowledging that they understand the
security risks and have taken all measures possible to protect the user's
system.
When trusted operations are performed, the security manager ensures the
object is trusted to perform the operation, and then the call stack is
crawled to ensure all callers are also trusted to make the call. A
SecurityExceptionEx[Host] or SecurityExceptionEx[Unknown] exception will be
thrown if an untrusted caller is found on the call stack.
The assertPermission(PermissionId pid) method in the PolicyEngine class
will prevent the security manager from crawling the call stack, enabling
your applet to perform trusted operations even when methods on the call
stack are not trusted. You should only assert your permission if you are
sure an untrusted member of the call stack cannot harm the users system. A
logical place to assert your permissions is at the beginning of the method
that is making the trusted call. Once this method returns, subsequent
public methods called from outside the virtual machine will also need to
assert permission before making trusted calls.
The PermissionID class has predefined granular permissions, such as NETIO,
FILEIO, and so forth. In order to grant full permissions to the applet use
the SYSTEM permission. This is needed for calling J/Direct, COM, and native
methods.
The following sample applet demonstrates reading a character from a Web
page, which is a trusted operation. This example needs to be trusted either
by placing the file in a signed cabinet file, running the project from
Developer Studio, or by placing the class in the classpath:
import com.ms.security.*;
import java.applet.Applet;
import java.net.*;
import java.io.*;
import java.awt.*;
public class myApplet1 extends Applet {
TextField message=null;
public myApplet1() {
message=new TextField();
setLayout(new BorderLayout());
add("Center",message);
}
public void init()
{
/*
Our init function needs to read a character from a URL, which is a
trusted operation. We assert NET permission to stop the stack
crawling since the Web page isn't trusted. The applet must be
signed so the init() function has permission to perform net
operations.
*/
try {
if (Class.forName("com.ms.security.PolicyEngine") != null) {
PolicyEngine.assertPermission(PermissionID.NETIO);
}
} catch (Throwable cnfe) {
}
try {
URL url = new URL("http://www.microsoft.com/");
DataInputStream dis;
dis = new DataInputStream(url.openConnection().getInputStream());
dis.readChar();
message.setText("Read character.");
} catch (MalformedURLException mue) {
message.setText("MalformedURL");
mue.printStackTrace();
} catch (Throwable t) {
message.setText(t.toString());
t.printStackTrace();
}
}
}
REFERENCES
For more information on using the com.ms.security package and for information on signing a Java cabinet file, see the documentation included with the Microsoft SDK for Java. For more information, visit the following Microsoft Web site:
For additional information on making your Java Code trusted in Microsoft
Internet Explorer, please refer to the following Knowledge Base article:
193877 HOWTO: Making your Java Code Trusted in Internet Explorer
For support information about Visual J++ and the SDK for Java, visit the following Microsoft Web site:
Modification Type: | Major | Last Reviewed: | 6/14/2006 |
---|
Keywords: | kbcode kbFAQ kbprb KB175622 |
---|
|