Signing Applets - Coding for Explorer
Usually, you won't have to modify your signed applet's code to work with Internet Explorer. However, you will have to use Microsoft's proprietary com.ms.security classes if you need to do "dangerous" actions in one of five places: in the applets default constructor, init(), start(), stop() or destroy() methods.

For example, if your applet is designed to read a file from the user's hard disk on startup, the obvious place to invoke the necessary method is from the applet's start() method. However, in this case Explorer will protest with a SecurityExceptionEx[Host] exception.

Basically, when a signed applet attempts a "dangerous" action, the Microsoft VM looks back down the call chain, looking for a method that is either clearly "trusted" or clearly "untrusted". A method is trusted if it uses com.ms.security.PolicyEngine.assertPermission() to assert the desired capability. A method is untrusted if it has been called from the outside world (e.g. init(), start(), stop() or destroy()).

There is a way to avoid using Microsoft's security classes: instead of having your init(), start(), stop() or destroy() method perform the "dangerous" action, have it start a thread which in turn performs the "dangerous" action.

Someday, I may make this description clearer. Until then, check out this Microsoft article telling when you might have to use their proprietary privilege assertion classes: <http://support.microsoft.com/support/kb/articles/q175/6/22.asp>.

Next section: Signing for Microsoft Internet Explorer

 

 

 
  
    Copyright © 2012 Daniel Griscom Site design myriadweb.com  
Home Page Home Page Home Page