Uno de los objetivos principales del entorno Java es hacer que los usuarios de navegadores se sientan seguros cuando ejecutan cualquier applet. Para conseguir este objetivo, hemos empezado conservadores, restringiendo las capacidades, quizás más necesarias. Cuando pase el tiempo los applets probablemente tendrán más y más capacidades.

Esta página cuenta las restricciones de seguridad actuales en los applets, desde el punto de vista del cómo afecta el diseño de applets.

Cada visualizador de Applets tiene un objeto SecurityManager que comprueba las violaciones de seguridad de un applet. Cuando el SecurityManager detecta una violación, crea y lanza un objeto SecurityException. Generalmente, el constructor de la SecurityException imprime un mensaje de aviso en la salida estandard. Un applet puede capturar esa excepción y reaccionar de forma apropiada, como tranquilizar al usuairo y saltando a una forma "segura" (pero menos ideal) para realizar la tarea,

Algunos visualizadores de applets se tragan algunas SecurityException, para que el applet nunca pueda capturarlas. Por ejemplo, la implementación de los métodos getApplet() y getApplets() del AppletContext del Applet Viewer del JDK simplemente capturan e ignoran cualquier SecurityException. El usuario puede ver un mensaje de error en la salida estandard, pero al menos el applet obtiene un resultado válido desde los métodos. Esto tiene algúnsentido, ya que getApplets() debería poder devolver cualquier applet válido que encontrara, incluso si encuentra uno no válido. (El Applet Viewer considera que un applet es válido si se ha cargado desde el mismo host que el applet que llamo a getApplets().)

Para aprender más sobre los controladores de seguriad y las clases de violaciones de seguridad que pueden comprobar, puedes ver Introducción a los Manejadores de Seguridad.

Cómo se menciona en la lección anterior, los visualizadores de applets existentes (incluyendo los navegadores de la Web como Netscape Navigator 2.0) imponen las siguientes restricciones:

Los Applets no pueden cargar librerías ni definir métodos nativos.

Los applets sólo pueden utilizar su propio código Java y el API Java que le proporciona el visualizador. Como mínimo, cada visualizador de applets debe proporcionar acceso al API definido en los paquetes java.*.

Un applet no puede leer o escribir ficheros de forma ordinaria en el host donde se está ejecutando

El Applet Viewer del JDK permite algunas excepciones especificadas por el usuario a esa regla, pero Nestcape Navigator 2.0 no lo permite. Los applets en cualquier visualizador pueden leer ficheros especificados con una dirección URL completa, en vez por un nombre de fichero. Un atajo para no tener que escribir ficheros es hacer que el applet envíe los datos a una aplicación en el servidor de donde el es original. Esta aplicación puede escribir ficheros de datos en su propio servidor. Puedes ver Trabajar con una Aplicacion del Lado del Servidor para ver más ejemplos.

Un applet no puede hace conexiones de red excepto con el host del que el applet es original

El atajo para esta restricción es hacer que el applet trabaje con una aplicación en el host del que vino. La aplicación pude hacer conexiones a cualquier lugar de la red.

Un applet no puede arrancar ningún programa en el host donde se está ejecutando

De nuevo, el applet puede trabajar con una aplicación en el lado del servidor en su lugar.

Un applet no puede leer todas las propiedades del sistema.

Puedes ver Leer las Propiedades del Sistema para obtener más información.

Las ventanas que genera una applet son distintas a las ventanas que genera una aplicación.

Las ventanas de applet tiene algún texto de aviso y una barra coloreada o una imagen. Esto ayuda al usuario a distinguir las ventanas de los applets de las ventanas de las aplicaciones verdaderas.

---

Ozito