Most application services use a singleton object to provide their services, either as a default (such as getSystemEventQueue or getDefaultToolkit) or as static methods with class data (System). The AppContext works with the former method by extending the concept of "default" to be ThreadGroup-specific. Application services lookup their singleton in the AppContext.
For example, here we have a Foo service, with its pre-AppContext code:
public class Foo { private static Foo defaultFoo = new Foo(); public static Foo getDefaultFoo() { return defaultFoo; } ... Foo service methods }
The problem with the above is that the Foo service is global in scope, so that applets and other untrusted code can execute methods on the single, shared Foo instance. The Foo service therefore either needs to block its use by untrusted code using a SecurityManager test, or restrict its capabilities so that it doesn't matter if untrusted code executes it.
Here's the Foo class written to use the AppContext:
public class Foo { public static Foo getDefaultFoo() { Foo foo = (Foo)AppContext.getAppContext().get(Foo.class); if (foo == null) { foo = new Foo(); getAppContext().put(Foo.class, foo); } return foo; } ... Foo service methods }
Since a separate AppContext can exist for each ThreadGroup, trusted and untrusted code have access to different Foo instances. This allows untrusted code access to "system-wide" services -- the service remains within the AppContext "sandbox". For example, say a malicious applet wants to peek all of the key events on the EventQueue to listen for passwords; if separate EventQueues are used for each ThreadGroup using AppContexts, the only key events that applet will be able to listen to are its own. A more reasonable applet request would be to change the Swing default look-and-feel; with that default stored in an AppContext, the applet's look-and-feel will change without disrupting other applets or potentially the browser itself.
Because the AppContext is a facility for safely extending application service support to applets, none of its methods may be blocked by a a SecurityManager check in a valid Java implementation. Applets may therefore safely invoke any of its methods without worry of being blocked. Note: If a SecurityManager is installed which derives from ae.sun.awt.AWTSecurityManager, it may override the AWTSecurityManager.getAppContext() method to return the proper AppContext based on the execution context, in the case where the default ThreadGroup-based AppContext indexing would return the main "system" AppContext. For example, in an applet situation, if a system thread calls into an applet, rather than returning the main "system" AppContext (the one corresponding to the system thread), an installed AWTSecurityManager may return the applet's AppContext based on the execution context. @author Thomas Ball @author Fred Ecks
Most application services use a singleton object to provide their services, either as a default (such as getSystemEventQueue or getDefaultToolkit) or as static methods with class data (System). The AppContext works with the former method by extending the concept of "default" to be ThreadGroup-specific. Application services lookup their singleton in the AppContext.
For example, here we have a Foo service, with its pre-AppContext code:
public class Foo { private static Foo defaultFoo = new Foo(); public static Foo getDefaultFoo() { return defaultFoo; } ... Foo service methods }
The problem with the above is that the Foo service is global in scope, so that applets and other untrusted code can execute methods on the single, shared Foo instance. The Foo service therefore either needs to block its use by untrusted code using a SecurityManager test, or restrict its capabilities so that it doesn't matter if untrusted code executes it.
Here's the Foo class written to use the AppContext:
public class Foo { public static Foo getDefaultFoo() { Foo foo = (Foo)AppContext.getAppContext().get(Foo.class); if (foo == null) { foo = new Foo(); getAppContext().put(Foo.class, foo); } return foo; } ... Foo service methods }
Since a separate AppContext can exist for each ThreadGroup, trusted and untrusted code have access to different Foo instances. This allows untrusted code access to "system-wide" services -- the service remains within the AppContext "sandbox". For example, say a malicious applet wants to peek all of the key events on the EventQueue to listen for passwords; if separate EventQueues are used for each ThreadGroup using AppContexts, the only key events that applet will be able to listen to are its own. A more reasonable applet request would be to change the Swing default look-and-feel; with that default stored in an AppContext, the applet's look-and-feel will change without disrupting other applets or potentially the browser itself.
Because the AppContext is a facility for safely extending application service support to applets, none of its methods may be blocked by a a SecurityManager check in a valid Java implementation. Applets may therefore safely invoke any of its methods without worry of being blocked. Note: If a SecurityManager is installed which derives from sun.awt.AWTSecurityManager, it may override the AWTSecurityManager.getAppContext() method to return the proper AppContext based on the execution context, in the case where the default ThreadGroup-based AppContext indexing would return the main "system" AppContext. For example, in an applet situation, if a system thread calls into an applet, rather than returning the main "system" AppContext (the one corresponding to the system thread), an installed AWTSecurityManager may return the applet's AppContext based on the execution context. @author Thomas Ball @author Fred Ecks
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |