Determina el modo en que Flash Player elige el dominio que se utiliza para determinadas configuraciones, incluida la configuración para permisos de cámaras y micrófonos, cuotas de almacenamiento y almacenamiento de objetos compartidos persistentes. Para que el archivo SWF utilice la misma configuración que en Flash Player 6, se puede definir exactSettings como false.

En Flash Player 6, el dominio utilizado para esta configuración del reproductor se basaba en el fragmento final del dominio del archivo SWF. Si el dominio de un archivo SWF contiene más de dos segmentos, como en www.example.com, se elimina el primer segmento del dominio ("www") y se utiliza el fragmento restante: example.com. De este modo, en Flash Player 6, tanto www.example.com como store.example.com utilizan example.com como dominio para esta configuración. Del mismo modo, tanto www.example.co.uk como store.example.co.uk utilizan example.co.uk como dominio para esta configuración. En Flash Player 7 y versiones posteriores, la configuración del reproductor se elige de forma predeterminada según el dominio exacto del archivo SWF; por ejemplo, un archivo SWF de www.example.com utiliza la configuración del reproductor para www.example.com y un archivo SWF de store.example.com utiliza la configuración del reproductor independiente para store.example.com.

Si Security.exactSettings se define como true, Flash Player utiliza dominios exactos para la configuración del reproductor. Si se define como false, Flash Player utiliza la configuración de dominio empleada en Flash Player 6. El valor predeterminado para exactSettings es true. Si cambia el valor predeterminado de exactSettings, debe hacerlo antes de que se produzca ningún evento que requiera que Flash Player elija la configuración del reproductor; por ejemplo, con una cámara o un micrófono, o bien, recuperando un objeto compartido persistente.

Si ya ha publicado anteriormente un archivo SWF de la versión 6, ha creado objetos compartidos persistentes a partir de él y ahora necesita recuperarlo del archivo SWF tras migrar a una versión 7 o posterior, debe definir Security.exactSettings como false antes de llamar a SharedObject.getLocal().

Véase también

Indica el tipo de entorno limitado de seguridad en el que actúa el archivo SWF.

Security.sandboxType tiene uno de los valores siguientes:

• remote (Security.REMOTE): este archivo SWF procede de una URL de Internet y se rige por reglas de entorno limitado basado en dominio.
• localWithFile (Security.LOCAL_WITH_FILE): este SWF es un archivo local y no es de confianza para el usuario. No se ha publicado en una designación de red. El archivo SWF puede leer en orígenes de datos locales, pero no puede comunicarse con Internet.
• localWithNetwork (Security.LOCAL_WITH_NETWORK): este SWF es un archivo local y no es de confianza para el usuario. Se ha publicado en una designación de red. El archivo SWF se puede comunicar con Internet pero no puede leer en fuentes de datos locales.
• localTrusted (Security.LOCAL_TRUSTED): este SWF es un archivo local y el usuario ha determinado que es de confianza, mediante el Administrador de configuración o un archivo de configuración FlashPlayerTrust. El archivo SWF puede leer en orígenes de datos locales y puede comunicarse con Internet.

Un archivo SWF de cualquier versión puede utilizar esta propiedad, pero sólo se admite en Flash Player 8 o versiones posteriores. Por tanto, puede examinar la propiedad, por ejemplo, desde un archivo SWF de la versión 7 reproducido en Flash Player 8. Ser compatible con todas las versiones implica que si publica para una versión anterior a la 8, en el momento de la publicación no sabrá si se admitirá esta propiedad cuando se realice la reproducción. Por lo tanto, en un archivo SWF de la versión 7 o anterior, esta propiedad puede tener un valor undefined, lo que sólo debería pasar cuando la versión del reproductor (indicada en flash.system.Capabilities.version) sea anterior a la 8. En este caso, puede determinar el tipo de entorno limitado dependiendo de si el archivo SWF es local o no. Si es un archivo local, Flash Player lo clasificará como localTrusted. (Antes de Flash Player 8, así es como se trataba todo el contenido local.) Si no es un archivo local, Flash Player lo clasificará como remote.

Para más información, consulte las siguientes secciones:

• El capítulo de seguridad de la guía Programación con ActionScript 3.0 y los últimos comentarios realizados en LiveDocs.
• El documento técnico sobre la seguridad de Flash Player 9.

Véase también

Permite a los archivos SWF y HTML de los dominios identificados acceder a los objetos y variables del archivo SWF que contiene la llamada allowDomain().

Si hay dos archivos SWF en el mismo dominio (por ejemplo, http://misitio.com/swfA.swf y http://misitio.com/swfB.swf), el archivo swfA.swf puede examinar y modificar variables, objetos, propiedades, métodos, etc. en swfB.swf, y swfB.swf puede hacer lo mismo en swfA.swf. Esto se denomina uso de scripts entre películas o uso de scripts.

Si los dos archivos SWF están en dominios diferentes (por ejemplo, http://mysite.com/swfA.swf y http://othersite.com/siteB.swf), de forma predetermina Flash Player no permite a swfA.swf usar scripts en swfB.swf, ni viceversa. Un archivo SWF proporciona archivos SWF de otros dominios llamando a Security.allowDomain(). Esto se denomina creación de scripts en varios dominios. Al llamar a Security.allowDomain("siteA.com"), siteB.swf concede permiso a siteA.swf para hacer scripts.

En cualquier operación entre dominios, es importante tener claro qué dos partes están involucradas. En esta sección, llamaremos parte que accede a la que usa scripts entre películas (normalmente el archivo SWF que accede a otro) y parte a la que se accede a la otra (por lo general, el archivo SWF al que se accede). Si siteA.swf usa scripts en siteB.swf, siteA.swf será la parte que accede y siteB.swf será la parte a la que se accede.

Los permisos entre dominios establecidos con allowDomain() son asimétricos. En el ejemplo anterior, siteA.swf puede usar scripts en siteB.swf, pero siteB.swf no puede hacerlo en siteA.swf, ya que siteA.swf no ha llamado a allowDomain() para dar permiso a los archivos SWF de siteB.com para hacer scripts. Puede establecer permisos simétricos si ambos archivos SWF llaman a allowDomain().

Flash Player protege los archivos SWF no sólo de los scripts creados en varios dominios por otros archivos SWF, sino también de los originados por archivos HTML. Los scripts de HTML se pueden usar en SWF mediante el uso de interfaces API anteriores del navegador Flash, como SetVariable o invocando las funciones callback definidas a través de ExternalInterface.addCallback(). Cuando el uso de scripts de HTML en SWF traspasa los dominios, el archivo SWF debe llamar a allowDomain() para evitar que la operación falle, tanto si es la parte que accede como si es la parte a la que se accede.

Cuando se especifica una dirección IP como parámetro en allowDomain(), no se permite el acceso de las partes con origen en la dirección IP especificada. Sólo se permite el acceso a la parte que contiene la dirección IP especificada en su URL y no un nombre de dominio que corresponda a la dirección IP.

Diferencias específicas entre versiones

Las reglas de seguridad entre dominios de Flash Player han evolucionado de una versión a otra. En la tabla siguiente, se resumen las diferencias.

Las versiones que controlan el comportamiento de Flash Player son las versiones de SWF (versión publicada de un SWF), no las versiones del propio Flash Player. Por ejemplo, cuando Flash Player 8 reproduce un archivo SWF de la versión 7, presenta un comportamiento coherente con la versión 7. Esta práctica evita que las actualizaciones del reproductor modifiquen el comportamiento de Security.allowDomain() en los archivos SWF implementados.

En la tabla anterior, la columna de la versión se reserva para la versión de SWF más reciente que interviene en el uso de scripts entre películas. Flash Player determina su comportamiento en función de la versión del archivo SWF que accede o de la versión del SWF al que se accede, la que sea más reciente.

Los párrafos siguientes ofrecen más detalles acerca de los cambios en la seguridad de Flash Player que están relacionados con Security.allowDomain().

Versión 5. Creación de scripts en varios dominios sin restricciones.

Versión 6. Se incorpora la función de seguridad para la creación de scripts entre dominios. Flash Player prohíbe la creación de scripts entre dominios de forma predeterminada; Security.allowDomain() puede permitirla. Para determinar si dos archivos pertenecen al mismo dominio, Flash Player utilizar el superdominio de cada archivo, que es el nombre exacto del host de la URL del archivo, menos el primer segmento, hasta un mínimo de dos segmentos. Por ejemplo, el superdominio de www.mysite.com es mysite.com. Este ejemplo permitirá el uso de scripts entre los archivos SWF de www.mysite.com y store.mysite.com sin llamar a Security.allowDomain().

Versión 7. La coincidencia de superdominios se cambia por la coincidencia exacta de dominios. Sólo se permite el uso de scripts entre dos archivos si los nombres del host en las URL son idénticos; de lo contrario, se requiere una llamada a Security.allowDomain(). De forma predeterminada, ya no se permite que los archivos cargados desde direcciones URL que no sean HTTPS usen scripts en archivos con URL HTTPS, aunque los archivos se carguen desde el mismo dominio exactamente. Esta restricción ayuda a proteger los archivos HTTPS, ya que los archivos no HTTPS son susceptibles de modificarse durante la descarga. Cualquier cambio malintencionado en un archivo no HTTPS podría dañar los archivos HTTPS, que de lo contrario serían inmunes a tales ataques. Aunque Security.allowInsecureDomain() se ha introducido con el fin de permitir la desactivación voluntaria de esta restricción en los archivos SWF HTTPS a los que se accede, se desaconseja utilizar Security.allowInsecureDomain().

Versión 8. Los cambios afectan a dos áreas principalmente:

• La llamada a Security.allowDomain() permite ahora operaciones de script entre películas sólo cuando el archivo SWF al que se accede es el archivo SWF que realizó la llamada a Security.allowDomain(). Es decir, un archivo SWF que realiza una llamada a Security.allowDomain() ahora sólo permite que se acceda al propio archivo. En versiones anteriores, la llamada a Security.allowDomain() permitía operaciones de script entre películas en las que el archivo SWF al que se accedía podía ser cualquier archivo SWF del mismo dominio que el archivo que llamó a Security.allowDomain(). Anteriormente, la llamada a Security.allowDomain() abría todo el dominio del archivo SWF que realizaba la llamada.
• Se ha añadido la posibilidad de utilizar valores comodín con Security.allowDomain("*") y Security.allowInsecureDomain("*"). El valor comodín (*) permite operaciones de script entre películas en las que el archivo que accede puede ser cualquier archivo de cualquier procedencia. El comodín es un valor que otorga un permiso global. Los permisos de comodín son necesarios para activar ciertos tipos de operaciones en las reglas de seguridad de los archivos locales. En concreto, para que un archivo SWF local con permisos de acceso de red cree scripts en un archivo SWF de Internet, este último debe llamar a Security.allowDomain("*"), lo que refleja que se desconoce el origen del archivo SWF local. (Si el archivo SWF de Internet se carga desde una dirección URL HTTPS, el archivo debe llamar a Security.allowInsecureDomain("*").)

Es posible que, en ocasiones, se encuentre con la siguiente situación: el usuario carga un archivo SWF secundario de un dominio diferente y desea que el archivo SWF secundario pueda crear un script en el archivo SWF principal, pero no conoce el dominio final del archivo SWF secundario. Por ejemplo, esto puede ocurrir cuando se utilizan redirecciones de reparto de carga o servidores de terceros.

En esta situación, se puede utilizar la propiedad url del objeto URLRequest que se pasa a Loader.load(). Por ejemplo, si carga un archivo SWF secundario en uno principal, podrá acceder a la propiedad contentLoaderInfo del objeto Loader para el archivo SWF principal:

Security.allowDomain(loader.contentLoaderInfo.url)

Es importante que espere a que el archivo SWF secundario se comience a cargar para poder obtener el valor correcto de la propiedad url. Para determinar cuándo ha comenzado la carga del archivo SWF secundario, utilice el evento progress.

También se puede presentar la situación contraria; podría crear un archivo SWF secundario en el que desee que su archivo principal use scripts, pero no conoce cuál será el dominio de su archivo principal. En este caso, se puede acceder a la propiedad loaderInfo del objeto de visualización que sea el objeto raíz del archivo SWF. En el archivo SWF secundario, llame a Security.allowDomain( this.root.loaderInfo.loaderURL). No es necesario esperar a que se cargue el archivo SWF principal; el archivo principal ya estará cargado en el momento que se cargue el secundario.

Si está publicando en Flash Player 8 o posterior, puede resolver estas situaciones llamando a Security.allowDomain("*"). No obstante, a veces puede tratarse de una solución rápida pero peligrosa, ya que será posible acceder al archivo SWF que hace la llamada desde cualquier dominio. Por lo general, resulta más seguro utilizar la propiedad _url.

Para más información, consulte las siguientes secciones:

• El capítulo de seguridad de la guía Programación con ActionScript 3.0 y los últimos comentarios realizados en LiveDocs.
• El documento técnico sobre la seguridad de Flash Player 9.

Parámetros

Véase también

Permite a los archivos SWF y HTML de los dominios identificados acceder a los objetos y variables del archivo SWF, que se aloja mediante el protocolo HTTPS. No se recomienda este método; consulte la sección "Consideraciones de seguridad" más adelante en esta entrada.

Este método funciona de la misma manera que Security.allowDomain(), pero además admite operaciones en las que la parte que accede se carga con un protocolo distinto de HTTPS y la parte a la que se accede se carga con protocolo HTTPS. En Flash Player 7 y versiones posteriores, no se permite el uso de scripts de archivos no HTTPS en archivos HTTPS. El método allowInsecureDomain() elimina esta restricción cuando el archivo SWF HTTPS al que se accede lo utiliza.

Utilice allowInsecureDomain() solamente para permitir el uso de scripts de archivos no HTTPS en archivos HTTPS. También se puede usar para permitir la creación de scripts cuando el archivo no HTTPS que accede y el archivo HTTPS al que se accede pertenecen al mismo dominio; por ejemplo, si un archivo SWF ubicado en http://mysite.com desea usar scripts en https://mysite.com. No utilice este método para permitir el uso de scripts entre archivos no HTTPS, entre archivos HTTPS o de archivos HTTPS en archivos no HTTPS. En esos casos debe utilizar allowDomain().

Consideraciones de seguridad: Aunque Flash Player ofrece allowInsecureDomain() para aumentar la flexibilidad, no se recomienda llamar a este método. Mediante la llamada a allowInsecureDomain se reduce la eficacia de algunas de las protecciones que proporciona a todos los usuarios la descarga de archivos a través de HTTPS. En el siguiente escenario se muestra cómo allowInsecureDomain() puede afectar a la seguridad si no se utiliza con cuidado.

Tenga en cuenta que la siguiente información sólo hace referencia a una posible situación y tiene por objeto ayudar a entender allowInsecureDomain() mediante un ejemplo práctico de uso de scripts entre películas. No abarca todos los aspectos relacionados con la arquitectura de seguridad y sólo debe utilizarse como información de referencia. En Flash Player Developer Center encontrará información detallada sobre Flash Player y la seguridad. Para más información, consulte http://www.adobe.com/devnet/security/.

Suponga que está creando un sitio de comercio electrónico que consta de dos componentes: un catálogo, que no requiere seguridad porque incluye únicamente información pública, y un componente de carrito de compra/finalización de la compra que debe asegurar para proteger los datos financieros y personales del usuario. Supongamos que desea que el catálogo esté disponible en http://mysite.com/catalog.swf y el carrito en https://mysite.com/cart.swf. Uno de los requisitos del sitio es evitar que un tercero pueda hacerse con el número de la tarjeta de crédito de los usuarios aprovechándose de un punto débil en la arquitectura de seguridad.

Imagine que un atacante de una parte intermedia interviene entre el servidor y los usuarios e intenta obtener los números de las tarjetas de crédito de los usuarios que acceden a la aplicación del carrito de la compra. La parte intermedia puede ser, por ejemplo, un ISP sin escrúpulos que utilicen algunos de sus usuarios o un administrador malintencionado del lugar de trabajo del usuario; es decir, cualquiera que pueda ver o alterar los paquetes de red que circulan por un sitio de Internet público entre sus usuarios y servidores. Este atributo no es necesario.

Si cart.swf utiliza el protocolo HTTPS para trasmitir la información de la tarjeta de crédito a sus servidores, la parte intermedia no puede obtener directamente esta información de los paquetes de red, ya que las transmisiones HTTPS están cifradas. Sin embargo, el atacante puede utilizar una técnica diferente: modificar el contenido de uno de los archivos SWF cuando se envía al usuario y reemplazarlo con la versión modificada, que transmite la información del usuario a un servidor diferente, propiedad del atacante.

Entre otras cosas, el protocolo HTTPS impide que los ataques de "modificación" den resultados, ya que las transmisiones HTTPS, además de estar cifradas, resisten cualquier intento de ataque: si una parte intermedia altera un paquete, la parte receptora detecta la modificación y descarta el paquete. En este caso, el atacante no puede modificar el archivo cart.swf porque se transmite a través de HTTPS.

Sin embargo, supongamos que quiere contar con botones en catalog.swf, disponible en HTTP, para añadir artículos al carrito de la compra de cart.swf, disponible en HTTPS. Para conseguirlo, cart.swf llama a allowInsecureDomain(), que permite a catalog.swf crear scripts en cart.swf. Esta acción tiene una consecuencia no deseada: ahora el atacante puede alterar catalog.swf cuando el usuario lo descarga por primera vez, ya que el protocolo de transmisión de catalog.swf es HTTP y no resiste ataques. Como cart.swf contiene una llamada a allowInsecureDomain(), el archivo catalog.swf modificado puede crear scripts en cart.swf. El archivo catalog.swf modificado puede utilizar ActionScript para acceder a las variables de cart.swf, por lo que se podrá leer la información de la tarjeta de crédito y otros datos confidenciales del usuario. Además, puede enviar estos datos al servidor de un atacante.

Aunque, obviamente, esta no es la solución deseada, todavía desea permitir el uso de scripts entre películas entre los dos archivos SWF de su sitio. A continuación se exponen las dos formas posibles de rediseñar este hipotético sitio de comercio electrónico para evitar allowInsecureDomain():

• Ponga a disposición todos los SWF de la aplicación a través de HTTPS. Esta es, sin duda, la solución más sencilla y fiable. En la situación descrita, tanto catalog.swf como cart.swf estarán disponibles a través de HTTPS. Puede detectar un ligero aumento del consumo del ancho de banda y de la carga de la CPU del servidor al cambiar un archivo como catalog.swf de HTTP a HTTPS. Además, es posible que los usuarios tengan que soportar una pequeña ralentización de los tiempos de carga de la aplicación. Por ello es necesario experimentar con servidores reales para determinar el alcance de estos efectos, que normalmente no suelen suponer aumentos de más del 10-20% en cada caso, y a veces ni se producen. Los resultados pueden mejorar con el uso de hardware o software de aceleración de HTTPS en los servidores. Una de las ventajas más importantes que ofrece la disponibilidad de los archivos SWF que operan conjuntamente a través de HTTPS es que puede utilizar una URL HTTPS como URL principal en el navegador del usuario sin que el navegador genere mensajes de advertencia de contenido mixto. Además, el icono en forma de candado del navegador queda visible, por lo que el usuario dispone de un indicador de seguridad común y fiable.
• Use scripts de HTTPS en HTTP, en lugar de hacerlo a la inversa (HTTP en HTTPS). En la situación descrita, podría almacenar el contenido del carrito de la compra del usuario en catalog.swf y hacer que cart.swf sólo gestionase el proceso de finalización de la compra. En el momento de finalizar la compra, cart.swf podría recuperar el contenido del carrito desde las variables de ActionScript incluidas en catalog.swf. La restricción de uso de scripts de HTTP en HTTPS es asimétrica; mientras que no se puede permitir que un archivo catalog.swf transmitido por HTTP use scripts en un archivo cart.swf de HTTPS sin excluir riesgos, el archivo cart.swf de HTTPS puede usar scripts en el archivo catalog.swf de HTTP. Este método está más expuesto a contingencias que el método en el que todo está en HTTPS. Dada su vulnerabilidad a los ataques, debe tener cuidado con los archivos SWF transmitidos por HTTP. Por ejemplo, cuando cart.swf recupera la variable de ActionScript que describe el contenido del carrito, el código de ActionScript incluido en cart.swf no puede garantizar que el valor de esta variable tenga el formato previsto. Por tanto, debe comprobar que el carrito no contenga datos no válidos que podrían inducir a cart.swf a realizar una acción no deseada. También debe asumir el riesgo de que una parte intermedia altere catalog.swf y pueda proporcionar datos válidos pero inexactos a cart.swf; por ejemplo, mediante la introducción de artículos en el carrito del usuario. El procedimiento normal de finalización de la compra reduce este riesgo en cierta medida, ya que presenta al usuario el contenido del carrito y el coste total de la compra para su aprobación. Sin embargo, el riesgo sigue existiendo.

En los navegadores Web se ha impuesto la separación entre los archivos HTTPS y no HTTPS durante años. Además, la situación descrita es un buena razón para aplicar esta restricción. Flash Player ofrece la posibilidad de omitir esta restricción de seguridad cuando es absolutamente imprescindible, pero asegurándose de considerar con atención las consecuencias antes de pasar a la acción.

Para más información, consulte las siguientes secciones:

• El capítulo de seguridad de la guía Programación con ActionScript 3.0 y los últimos comentarios realizados en LiveDocs.
• El documento técnico sobre la seguridad de Flash Player 9.

Parámetros

Véase también

Carga un archivo de política para distintos dominios de una ubicación especificada por el parámetro url. Flash Player utiliza archivos de política para determinar si se permite que las películas Flash carguen datos desde servidores que no sean el suyo propio.

De forma predeterminada, Flash Player busca archivos de política sólo en una ubicación: /crossdomain.xml en el servidor al que se ha solicitado una solicitud de carga de datos.

Con Security.loadPolicyFile(), Flash Player puede cargar archivos de política de ubicaciones arbitrarias, como se muestra en el siguiente ejemplo:

  Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");
  

De este modo, Flash Player recupera un archivo de política de la URL especificada. Los permisos otorgados por el archivo de política de dicha ubicación se aplicarán a todo el contenido del mismo nivel o de un nivel inferior de la jerarquía de directorios virtual del servidor. Por ejemplo, según el código anterior, estas líneas no emiten ninguna excepción:

 import flash.net.*;
  var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
  var loader:URLLoader = new URLLoader();
  loader.load(request);

  var loader2:URLLoader = new URLLoader();
  var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
  loader2.load(request2);
  

Sin embargo, el siguiente código sí emite una excepción de seguridad:

 import flash.net.*;
  var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
  var loader3:URLLoader = new URLLoader();
  loader3.load(request3);
  

Puede utilizar loadPolicyFile() para cargar los archivos de política que desee. Al considerar una solicitud que requiera un archivo de política, Flash Player siempre espera a que termine la descarga de archivos de política antes de denegar una solicitud. Como opción final, si no hay ningún archivo de política especificado con loadPolicyFile() que autorice una solicitud, Flash Player consulta la ubicación predeterminada original: /crossdomain.xml.

La utilización del protocolo xmlsocket con un número de puerto específico le permite recuperar archivos de política directamente de un servidor XMLSocket, como se muestra en el siguiente ejemplo:

  Security.loadPolicyFile("xmlsocket://foo.com:414");
  

De este modo, Flash Player intenta recuperar un archivo de política desde el host y el puerto especificados. Puede utilizarse cualquier puerto, no sólo los puertos 1024 y superiores. Tras establecer una conexión con el puerto especificado, Flash Player transmite <policy-file-request />, terminada por un byte null. Puede configurarse un servidor XMLSocket para que responda a solicitudes de archivos de política y a conexiones XMLSocket normales en el mismo puerto; en este caso, el servidor deberá esperar <policy-file-request /> antes de transmitir un archivo de política. También puede configurarse un servidor para que responda a solicitudes de archivos de política en un puerto distinto de las conexiones estándar; en este caso, el servidor puede enviar un archivo de política cuando se establece una conexión en el puerto del archivo de política dedicado. El servidor debe enviar un byte nulo para terminar un archivo de política y más tarde puede cerrar la conexión; si el servidor no cierra la conexión, Flash Player la cerrará después de recibir el byte null de terminación.

Un archivo de política que proporciona un servidor XMLSocket tiene la misma sintaxis que cualquier otro archivo de política, pero debe especificar también los puertos a los que se concede el acceso. Si un archivo de política procede de un puerto inferior a 1024, dicho archivo puede conceder acceso a cualquier puerto; cuando un archivo de política procede del puerto 1024 o superior, sólo puede conceder acceso a otros puertos 1024 y superiores. Los puertos permitidos se especifican en el atributo "to-ports" de la etiqueta <allow-access-from>. Los números de puerto únicos, los intervalos de puertos y los comodines están permitidos. El ejemplo siguiente, se muestra un archivo de política XMLSocket:

  <cross-domain-policy>
    <allow-access-from domain="*" to-ports="507" />
    <allow-access-from domain="*.foo.com" to-ports="507,516" />
    <allow-access-from domain="*.bar.com" to-ports="516-523" />
    <allow-access-from domain="www.foo.com" to-ports="507,516-523" />
    <allow-access-from domain="www.bar.com" to-ports="*" />
  </cross-domain-policy>
  

Un archivo de política procedente de la ubicación predeterminada original (/crossdomain.xml en un servidor HTTP del puerto 80) autoriza implícitamente el acceso a todos los puertos 1024 y superiores. No se puede recuperar un archivo de política que autorice operaciones de XMLSocket desde cualquier otra ubicación de un servidor HTTP; las ubicaciones personalizadas para los archivos de política XMLSocket deben estar en un servidor XMLSocket.

Se puede conceder la capacidad de conectar con puertos inferiores a 1024 mediante un archivo de política cargado sólo con loadPolicyFile().

Asimismo, puede evitar que un archivo SWF utilice este método, estableciendo el parámetro allowNetworking de las etiquetas object y embed en la página HTML que incluye el contenido de SWF.

Para más información, consulte las siguientes secciones:

• El capítulo de seguridad de la guía Programación con ActionScript 3.0 y los últimos comentarios realizados en LiveDocs.
• El documento técnico sobre la seguridad de Flash Player 9.

Parámetros

Véase también

Muestra el panel Parámetros de seguridad de Flash Player.

Parámetros

Véase también

El SWF es un archivo local y el usuario ha determinado que es de confianza, mediante el Administrador de configuración o un archivo de configuración FlashPlayerTrust. El archivo SWF puede leer en orígenes de datos locales y puede comunicarse con Internet.

Véase también

Este SWF es un archivo local y no es de confianza para el usuario. No se ha publicado con una designación de red. El archivo SWF puede leer en orígenes de datos locales, pero no puede comunicarse con Internet.

Véase también

Este SWF es un archivo local y no es de confianza para el usuario. Se ha publicado con una designación de red. El archivo SWF se puede comunicar con Internet pero no puede leer en fuentes de datos locales.

Véase también

Este archivo SWF procede de una URL de Internet y se rige por reglas de entorno limitado basado en dominio.

Véase también