Article ID: 175622 - View products that this article applies to.
This article has been archived. It is offered "as is" and will no longer be updated.
When running a Java applet, the security manager throws one of the following exceptions:
java.lang.SecurityException: J/Direct method has not been authorized for use on behalf of an untrusted caller.
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:
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:
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:
HOWTO: Making your Java Code Trusted in Internet ExplorerFor support information about Visual J++ and the SDK for Java, visit the following Microsoft Web site: