Security  - AS3

Determina como o Flash Player ou o AIR escolhe o domínio a ser usado para certas configurações, incluindo configurações para permissões de câmera e microfone, cotas de armazenamento e armazenamento de objetos compartilhados persistentes. Defina exactSettings como false para que o arquivo SWF use as mesmas configurações usadas no Flash Player 6.

No Flash Player 6, o domínio usado para essas configurações de player se baseava na parte posterior do domínio do arquivo SWF. Se o domínio do arquivo SWF incluir mais de dois segmentos, como www.example.com, o primeiro segmento do domínio ("www") será movido e a parte restante do domínio será usada. example.com. Assim, no Flash Player 6, www.example.com e store.example.com usam example.com como domínio dessas configurações. De modo semelhante, www.example.co.uk e store.example.co.uk usam example.co.uk como o domínio dessas configurações. No Flash Player 7 e posterior, as configurações de player são selecionadas, por padrão, de acordo com o domínio exato do arquivo SWF, por exemplo: um arquivo SWF de www.example.com usaria as configurações de player de www.example.com e o arquivo SWF de store.example.com usaria as configurações separadas de player de store.example.com.

Quando Security.exactSettings é definido como true, o Flash Player ou o AIR usa domínios exatos nas configurações de player. O valor padrão de exactSettings é true. Se você alterar o valor padrão de exactSettings, deverá fazê-lo antes de ocorrer algum evento que exija que o Flash Player ou o AIR escolha configurações de player, por exemplo, usando uma câmera ou um microfone ou recuperando um objeto compartilhado persistente.

Se você publicou anteriormente um arquivo SWF versão 6 e criou objetos compartilhados persistentes nessa versão, e agora precisa recuperar esses objetos persistentes do arquivo SWF depois de transportá-los para a versão 7 ou posterior, ou de um arquivo SWF diferente da versão 7 ou posterior, precisará definir Security.exactSettings como false antes de chamar SharedObject.getLocal().

A parte do domínio da página HTML que contém o swf.

Para motivos de segurança, o método não retorna a URL cheia, mas apenas o domínio de página, como http://www.example.com. Se este SWF não estiver contido em uma página HTML, ou não puder acessar o domínio da página por motivos de segurança, esta propriedade retornará a string, undefined.

Indica o tipo de área de segurança na qual o arquivo de chamada está operando.

Security.sandboxType tem um dos seguintes valores:

• remote (Security.REMOTE) - Esse arquivo SWF é proveniente de um URL da Internet e opera de acordo com as regras da caixa de proteção com base em domínio.
• O localWithFile (Security.LOCAL_WITH_FILE)— Este arquivo é um arquivo local, não foi confiado pelo usuário e não o arquivo SWF publicado com uma designação de rede. O arquivo pode ler de fontes de dados locais mas não pode se comunicar com a Internet.
• O localWithNetwork (Security.LOCAL_WITH_NETWORK)— Este arquivo SWF é um arquivo local, não foi confiado pelo usuário e foi publicado com uma designação de rede. O arquivo SWF pode se comunicar com a Internet mas não pode ler de fontes de dados locais.
• localTrusted (Security.LOCAL_TRUSTED) O arquivo é um arquivo local e foi confiado pelo usuário, seja usando o Gerenciador de configurações do Flash Player ou um arquivo de configuração FlashPlayerTrust. O arquivo pode ler de fontes de dados locais e se comunicar com a Internet.
• application (Security.APPLICATION)—Este arquivo está em execução em um aplicativo AIR e foi instalado com o pacote (arquivo AIR) para o aplicativo. Por padrão, os arquivos na caixa de proteção do aplicativo AIR podem cruzar script com qualquer arquivo de qualquer domínio (embora não seja permitido aos arquivos fora da caixa de proteção do AIR cruzar scripts com arquivos AIR). Por padrão, os arquivos na caixa de proteção do aplicativo AIR podem carregar o conteúdo e os dados de qualquer domínio.

Para obter mais informações relacionadas à segurança, consulte o tópico do Centro dos desenvolvedores do Flash Player Security.

Elementos da API relacionados

Permite que arquivos SWF dos domínios identificados acessem objetos e variáveis do arquivo SWF que contém a chamada allowDomain().

Observação: a chamada desse método a partir do código na área de segurança do aplicativo AIR lança uma exceção SecurityError. O conteúdo fora do domínio de segurança do aplicativo não pode cruzar diretamente o conteúdo dos scripts na caixa de proteção do aplicativo. No entanto, o conteúdo fora da caixa de proteção do aplicativo pode se comunicar com o conteúdo dessa caixa usando uma ponte de caixa de proteção.

Se dois arquivos SWF forem servidos no mesmo domínio, por exemplo, http://mysite.com/swfA.swf e http://mysite.com/swfB.swf, o swfA.swf poderá examinar e modificar variáveis, objetos, propriedades, métodos e assim por diante, no swfB.swf, e o swfB.swf pode fazer o mesmo no swfA.swf. Isso é chamado de script entre filmes ou entre scripts.

Se dois arquivos SWF forem servidos de domínios diferentes, por exemplo, http://siteA.com/swfA.swf e http://siteB.com/siteB.swf, por padrão, o Flash Player não permitirá que o swfA.swf faça script do swfB.swf, nem que o swfB.swf faça script do swfA.swf. O arquivo SWF dá permissão a arquivos SWF de outros domínios chamando Security.allowDomain(). Isso é chamado de script entre domínios. Ao chamar Security.allowDomain("siteA.com"), o siteB.swf concede ao siteA.swf permissão para fazer script.

Em qualquer situação entre domínios, é importante que as duas partes envolvidas sejam bem-definidas. Para fins desta discussão, o lado que executa o entre scripts é chamado de parte de acesso (normalmente o SWF que acessa) e o outro lado é chamado de a parte acessada (normalmente o arquivo SWF que está sendo acessado). Quando o siteA.swf faz script do siteB.swf, o siteA.swf é a parte que acessa e o siteB.swf é a parte acessada.

Permissões entre domínios estabelecidas com o allowDomain() são assimétricas. No exemplo anterior, o siteA.swf pode fazer script do siteB.swf, mas o siteB.swf não pode fazer script do siteA.swf, pois o siteA.swf não chamou o allowDomain() para dar permissão aos arquivos SWF para fazer script no siteB.com. Você pode configurar permissões simétricas fazendo com que ambos os arquivos SWF chamem oallowDomain().

Além de proteger arquivos SWF de script entre domínios originados por outros arquivos SWF, o Flash Player protege arquivos SWF de script entre domínios originados por arquivos HTML. O script de HTML para SWF pode ocorrer com funções antigas do navegador, como SetVariable ou retornos de chamadas estabelecidos por meio do ExternalInterface.addCallback(). Quando o script de HTML para SWF atravessa domínios, o arquivo SWF acessado deverá chamar allowDomain(), da mesma forma como quando a parte de acesso é um arquivo SWF, ou a operação apresentará falha.

Especificar um endereço IP como parâmetro de allowDomain() não permite o acesso das partes que se originam no endereço IP especificado. Em vez disso, permite o acesso apenas da parte que contém o endereço IP especificado em seu URL, em vez de um nome de domínio que é mapeado para o endereço IP.

Diferenças específicas da versão

As regras de segurança entre domínios do Flash Player foram evoluindo de versão para versão. A tabela seguinte resume as diferenças.

As versões que controlam o comportamento do Flash Player são as versões SWF (a versão publicada de um arquivo SWF) e não a versão do Flash Player. Por exemplo, quando o Flash Player 8 está reproduzindo um arquivo SWF publicado na versão 7, ele aplica um comportamento consistente com a versão 7. Essa prática assegura que as atualizações do player não alterem o comportamento do Security.allowDomain() em arquivos SWF implantados.

A coluna de versão na tabela anterior mostra a versão do SWF mais recente envolvida em uma operação entre scripts. O Flash Player determina o próprio comportamento de acordo com a versão do arquivo SWF de acesso ou com a versão do arquivo SWF acessado, a que for posterior.

Os parágrafos a seguir oferecem mais detalhes sobre alterações na segurança do Flash Player envolvendo o Security.allowDomain().

Versão 5. Não há restrições a script entre domínios.

Versão 6. A segurança de script entre domínios é introduzida. Por padrão, o Flash Player proíbe o script entre domínios e o Security.allowDomain() pode permiti-lo. Para determinar se dois arquivos estão no mesmo domínio, o Flash Player usa o superdomínio de cada arquivo, que é o nome exato de host do URL do arquivo, menos o primeiro segmento, abaixo um mínimo de dois segmentos. Por exemplo, o superdomínio de www.mysite.com é mysite.com. Arquivos SWF de www.mysite.com e store.mysite.com para fazer script entre si sem uma chamada para oSecurity.allowDomain().

Versão 7. A correspondência de superdomínio é alterada para correspondência de domínio exato. Dois arquivos só têm permissão de fazer script entre si se os nomes de host e respectivos URLs forem idênticos; caso contrário, será necessário uma chamada para o Security.allowDomain(). Por padrão, arquivos carregados de URLs não HTTPS não têm mais permissão de fazer scripts de arquivos de URLs HTTPS, ainda que os arquivos sejam carregados exatamente do mesmo domínio. Essa restrição ajuda a proteger arquivos HTTPS, pois o arquivo não HTTPS é vulnerável a modificações durante o download, e um arquivo não HTTPS modificado com más intenções pode corromper o arquivo HTTPS, que, do contrário, é imune a esse tipo de interceptação. O Security.allowInsecureDomain() foi introduzido para permitir que arquivos SWF HTTPS que estejam sendo acessados desativem voluntariamente essa restrição; o uso do Security.allowInsecureDomain(), no entanto, é desencorajado.

Versão 8. Há duas áreas principais de alteração:

• Chamar o Security.allowDomain() agora permitirá operações entre scripts somente se o arquivo SWF acessado for o arquivo SWF que chamou oSecurity.allowDomain(). Ou seja, o arquivo SWF que chama o Security.allowDomain() só permite agora acesso a ele mesmo. Em versões anteriores, chamar o Security.allowDomain() permitia operações entre scripts onde o arquivo SWF acessado poderia ser qualquer arquivo SWF no mesmo domínio do arquivo SWF que chamou oSecurity.allowDomain(). Chamar o Security.allowDomain() anteriormente abria o domínio inteiro do arquivo SWF que fazia a chamada.
• Foi adicionado suporte aos valores curingas com o Security.allowDomain("*") e o Security.allowInsecureDomain("*"). O valor curinga (*) permite operações entre scripts nas quais o arquivo que faz o acesso é qualquer arquivo, carregado de qualquer local. Considere o curinga como uma permissão global. São necessárias permissões de curinga para possibilitar alguns tipos de operações sob as regras locais de segurança de arquivo. Especificamente, em um arquivo SWF local com permissões de acesso à rede para fazer script de arquivo SWF na Internet, o arquivo SWF da Internet acessado deve chamar o Security.allowDomain("*"), refletindo que a origem de um arquivo SWF local é desconhecida. (Se o arquivo SWF da Internet for carregado de um URL HTTPS, em vez disso o arquivo SWF deverá chamar o Security.allowInsecureDomain("*").)

Ocasionalmente você pode encontrar a seguinte situação: Você carrega um arquivo SWF filho de um domínio diferente e deseja permitir que esse arquivo faça script do arquivo SWF pai, mas não conhece o domínio final do arquivo SWF filho. Isso pode acontecer, por exemplo, quando você usa redirecionamentos de balanceamento de carga ou servidores terceirizados.

Nessa situação, você pode usar a propriedade url do objeto URLRequest que você transmite para o Loader.load(). Por exemplo, se você carregar um arquivo SWF filho em um SWF pai, será possível acessar a propriedade contentLoaderInfo do objeto Loader do SWF pai:

Security.allowDomain(loader.contentLoaderInfo.url)

Espere até que o arquivo SWF comece a carregar para obter o valor correto da propriedade url. Para determinar quando o arquivo SWF filho começou a carregar, use o evento progress.

Uma situação contrária pode ocorrer também, ou seja, você pode criar um arquivo SWF filho que deseja permitir que o respectivo pai faça script, mas não sabe qual será o domínio do pai. Nessa situação, você pode acessar a propriedade loaderInfo do objeto de exibição que é o objeto raiz do SWF. No SWF filho, chame o Security.allowDomain( this.root.loaderInfo.loaderURL). Você não precisa esperar o arquivo SWF carregar, o pai já terá sido carregado quando o filho carregar.

Se você estiver publicando em Flash Player 8 ou superior, também poderá lidar com essas situações chamando o Security.allowDomain("*"). No entanto, às vezes isso pode ser um atalho perigoso, porque permite que o arquivo SWF que está chamando seja acessado por qualquer outro arquivo SWF de qualquer domínio. Geralmente é mais seguro usar a propriedade _url.

Para obter mais informações relacionadas à segurança, consulte o tópico do Centro dos desenvolvedores do Flash Player Security.

Parâmetros

Elementos da API relacionados

Permite que arquivos SWF e HTML dos domínios identificados acessem objetos e variáveis do arquivo SWF que está chamando, que é hospedado por meio do protocolo HTTPS.

O Flash Player oferece o allowInsecureDomain() para maximizar a flexibilidade, mas não é recomendável chamar esse método. Servir um arquivo em HTTPS oferece várias proteções para você e seus usuários, e chamar o allowInsecureDomain enfraquece uma dessas proteções.

Observação: a chamada desse método a partir do código na área de segurança do aplicativo AIR lança uma exceção SecurityError. O conteúdo fora do domínio de segurança do aplicativo não pode cruzar diretamente o conteúdo dos scripts na caixa de proteção do aplicativo. No entanto, o conteúdo fora da caixa de proteção do aplicativo pode se comunicar com o conteúdo dessa caixa usando uma ponte de caixa de proteção.

Esse método funciona da mesma maneira que o Security.allowDomain(), mas também permite operações em que a parte que acessa é carregada com um protocolo não HTTPS e a parte acessada é carregada com HTTPS. No Flash Player 7 e posterior, os arquivos não HTTP não têm permissão para fazer script de arquivos HTTPS. O método allowInsecureDomain() suspende essa restrição quando o arquivo SWF HTTPS que está sendo acessado a utiliza.

Use o allowInsecureDomain() somente para ativar script de arquivos não HTTPS para arquivos HTTPS. Use essa opção para ativar script quando o arquivo não HTTPS que está acessando e o arquivo HTTPS acessado são servidos no mesmo domínio, por exemplo, se um arquivo SWF em http://mysite.com quiser fazer script de um arquivo SWF em https://mysite.com. Não use esse método para ativar script entre arquivos não HTTPS, entre arquivos HTTPS, ou de arquivos HTTPS para arquivos não HTTPS. Em vez disso, nessas situações, use o allowDomain().

Observe que as seguintes informações representam apenas um possível cenário, desenvolvido para ajudá-lo a entender o allowInsecureDomain() em um exemplo entre scripts do mundo real. As informações não abrangem todos os problemas de arquitetura de segurança e devem ser usadas apenas como informações secundárias. O Centro de desenvolvedores do Flash Player contém informações extensas sobre o Flash Player e segurança. Para obter mais informações, consulte o tópico do Centro de desenvolvedores do Flash Player Security.

Suponhamos que você esteja criando um site comércio eletrônico que consiste em dois componentes: um catálogo, que não precisa ser seguro, porque contém apenas informações públicas, e um carrinho de compras/componente de baixa, que precisa ser seguro para proteger informações pessoais e financeiras do usuário. Suponhamos que você esteja considerando servir o catálogo de http://mysite.com/catalog.swf e o carrinho de https://mysite.com/cart.swf. Um requisito do seu site é que terceiros não consiga furtar números de cartão de crédito dos seus usuários, aproveitando-se de uma falha na arquitetura de segurança.

Suponhamos que um invasor intermediário interfira entre seu servidor e os usuários, tentando furtar números de cartão de crédito que seus usuários inserem no aplicativo de carrinho de compras. Um intermediário pode ser, por exemplo, um ISP (Internet Service Provider, provedor de serviços de Internet) inescrupuloso usado por alguns de seus usuários ou um administrador mal-intencionado no local de trabalho do usuário, qualquer pessoa que tenha a possibilidade de visualizar ou alterar pacotes de rede transmitidos pela Internet pública entre os usuários e servidores. Essa situação não é incomum.

Se o cart.swf usa HTTPS para transmitir informações de cartão de crédito para seus servidores, o invasor intermediário não pode roubar essas informações diretamente dos pacotes da rede, porque a transmissão HTTPS é criptografada. No entanto, o invasor poderá usar uma técnica diferente: alterar o conteúdo de um dos arquivos SWF quando ele é entregue ao usuário, substituindo o arquivo SWF por uma versão alterada que transmite as informações do usuário a um servidor diferente, pertencente ao invasor.

O protocolo HTTPS, entre outras coisas, impede que esse ataque de "modificação" funcione, pois além de serem criptografadas, as transmissões HTTPS são à prova de falsificação. Se um invasor intermediário altera um pacote, o lado que recebe detecta a alteração e descarta o pacote. Assim, o invasor nessa situação não consegue alterar o cart.swf, pois ele é entregue em HTTPS.

No entanto, suponhamos que você queira permitir botões no catalog.swf servidos em HTTP, para adicionar itens ao carrinho de compras no cart.swf servido em HTTPS. Para realizar isso, o cart.swf chama o allowInsecureDomain(), que permite que o catalog.swf faça script do cart.swf. Essa ação tem uma consequência inesperada: Agora o invasor pode alterar o catalog.swf no início do download pelo usuário, pois o catalog.swf é entregue com HTTP e não é à prova de falsificação. O catalog.swf alterado pelo invasor pode agora fazer script do cart.swf, pois o cart.swf contém uma chamada para o allowInsecureDomain(). O arquivo catalog.swf alterado pode usar o ActionScript para acessar as variáveis no cart.swf, lendo, dessa forma, as informações de cartão de crédito do usuário e outros dados confidenciais. O catalog.swf alterado pode, em seguida, enviar os dados para o servidor do invasor.

Obviamente, essa implementação não é desejável, mas você ainda deseja permitir entre scripts entre os dois arquivos SWF do site. Aqui estão duas maneiras possíveis de se redefinir esse site hipotético de comércio eletrônico para evitar o allowInsecureDomain():

• Servir todos os arquivos SWF do aplicativo em HTTPS. Essa é de longe a solução mais simples e mais confiável. No cenário descrito, você serve o catalog.swf e o cart.swf em HTTPS. Você pode passar por um consumo um pouco maior de largura de banda e carga de CPU do servidor quando alternar um arquivo como o catalog.swf de HTTP para HTTPS, e seus usuários podem experimentar um tempo um pouco maior de carregamento de aplicativo. Você precisa tentar em servidores reais para determinar a gravidade desses efeitos; geralmente não passam de 10 a 20% cada, e algumas vezes nem chegam a estar presentes. Geralmente você pode melhorar os resultados usando software ou hardware de aceleração HTTPS nos servidores. O principal benefício de servir todos os arquivos auxiliares SWF em HTTPS é que você pode usar um URL HTTPS como URL principal no navegador do usuário sem gerar nenhum aviso de conteúdo misturado no navegador. Além disso, o ícone de cadeado do navegador se torna visível, oferecendo aos usuários um indicador de segurança comum e confiável.
• Use script de HTTPS para HTTP, em vez de script de HTTP para HTTPS. No cenário descrito, você pode armazenar o conteúdo do carrinho de compras do usuário no catalog.swf e fazer com que o cart.swf gerencie apenas o processo de dar baixa. Na hora de dar baixa, o cart.swf pode recuperar o conteúdo do carrinho nas variáveis do ActionScript no catalog.swf. A restrição no script de HTTP para HTTPS é assimétrica; embora um arquivo catalog.swf entregue por HTTP não possa ser liberado com segurança para script do arquivo cart.swf entregue por HTTPS, o arquivo cart.swf HTTPS pode fazer script do arquivo catalog.swf HTTP. Essa abordagem é mais delicada do que todas as abordagem HTTPS; você deve ter cuidado e não confiar em nenhum arquivo SWF entregue em HTTP, devido à sua vulnerabilidade à falsificação. Por exemplo, quando o cart.swf recupera a variável ActionScript que descreve o conteúdo do carrinho, o código ActionScript no cart.swf não pode confiar que o valor dessa variável esteja no formato esperado. Você deve verificar se o conteúdo do carrinho não contém dados inválidos que possam levar o cart.swf a executar uma ação indesejada. Você também deve aceitar o risco de que um intermediário, alterando o catalog.swf, possa fornecer dados válidos mas imprecisos ao cart.swf, por exemplo, colocando itens no carrinho do usuário. O processo normal de dar baixa diminui o risco de certa forma, exibindo o conteúdo do carrinho e o custo total para aprovação final do usuário, mas o risco permanece presente.

Navegadores da Web impuseram a separação entre arquivos HTTPS e não HTTPS durante anos e o cenário descrito ilustra uma boa razão para essa restrição. O Flash Player oferece a possibilidade de contornar essa restrição de segurança quando for absolutamente necessário, mas certifique-se de considerar as consequências cuidadosamente antes de fazer isso.

Para obter mais informações relacionadas à segurança, consulte o tópico do Centro dos desenvolvedores do Flash Player Security.

Parâmetros

Elementos da API relacionados

Procura um arquivo de diretivas em um local especificado pelo parâmetro url. O Adobe AIR e o Flash Player usam arquivos de diretivas para determinar se será permitido que aplicativos carreguem dados de outros servidores que não sejam os seus. Observe que embora o nome do método seja loadPolicyFile(), o arquivo não será carregado realmente até que seja feita uma solicitação de rede que requer um arquivo de diretivas.

Com o Security.loadPolicyFile(), o Flash Player ou o AIR pode carregar arquivos de diretivas de locais arbitrários, conforme mostra o seguinte exemplo:

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

Isso faz com que o Flash Player ou o AIR tente se recuperar de um arquivo de diretivas do URL especificado. Qualquer permissão concedida pelo arquivo de diretivas nesse local será aplicada a todo conteúdo no mesmo nível ou mais baixo na hierarquia virtual de diretórios do servidor.

Por exemplo, seguindo o código anterior, estas linhas não lançam uma exceção:

 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);
     

No entanto, o código a seguir lança uma exceção de segurança:

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

Você pode usar o loadPolicyFile() para carregar qualquer número de arquivos de diretivas. Ao considerar uma solicitação que requer um arquivo de diretivas, o Flash Player ou o AIR sempre aguarda o término de algum download de arquivo de diretivas antes de negar uma solicitação. Como fallback final, se nenhum arquivo de diretivas especificado com o loadPolicyFile() autorizar a solicitação, o Flash Player ou o AIR consultará os locais padrão originais.

Ao verificar um arquivo de política mestre, o Flash Player aguarda três segundos por uma resposta do servidor. Se uma resposta não for recebida, o Flash Player assumirá que não existe nenhum arquivo de política. No entanto não há nenhum valor de tempo limite padrão para chamadas para loadPolicyFile(). O Flash Player assume que o arquivo que está chamando existe, e aguarda quanto tempo for necessário para carregá-lo. Portanto, para verificar se um arquivo de política mestre está carregado, use loadPolicyFile() para chamá-lo explicitamente.

Não é possível conectar-se às portas normalmente reservadas. Para ver uma lista completa de portas bloqueadas, consulte "Restrição de APIs de rede" no Guia do Desenvolvedor do ActionScript 3.0.

Use o protocolo xmlsocket juntamente com um número de porta específico para recuperar arquivos de diretivas diretamente de um servidor XMLSocket, conforme mostra o exemplo a seguir. As conexões de soquete não estão sujeitas à restrição de porta reservada descrita anteriormente.

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

Isso faz com que o Flash Player ou o AIR tente recuperar o arquivo de diretivas do host e da porta especificados. Ao estabelecer uma conexão com a porta especificada, o Flash Player ou o AIR transmite a <policy-file-request />, encerrada por um byte null. O servidor deve enviar um byte nulo para encerrar um arquivo de diretivas, e poderá depois fechar a conexão; se o servidor não fechar a conexão, o Flash Player ou o AIR o fará ao receber o byte null de encerramento.

Você pode impedir o arquivo SWF de usar esse método definindo o parâmetro allowNetworking das tags object e embed na página HTML com o conteúdo SWF.

Para obter mais informações relacionadas à segurança, consulte o tópico do Centro dos desenvolvedores do Flash Player Security.

Parâmetros

Exibe o painel Configurações de segurança no Flash Player. Este método não se aplica ao conteúdo no Adobe AIR; a chamada ao aplicativo AIR não faz efeito.

Parâmetros

Elementos da API relacionados

O arquivo está em execução em um aplicativo AIR e foi instalado com o pacote (arquivo AIR) para o aplicativo. Este conteúdo está incluído no diretório de recursos do aplicativo AIR (onde o conteúdo do aplicativo está instalado).

Elementos da API relacionados

O arquivo SWF é um arquivo local e foi confiado pelo usuário, seja usando o Gerenciador de configurações do Flash Player ou um arquivo de configuração FlashPlayerTrust. O arquivo pode ler de fontes de dados locais e se comunicar com a Internet.

Elementos da API relacionados

O arquivo é um arquivo local, não foi confiado pelo usuário e não é um arquivo SWF publicado com uma designação de rede. No Adobe AIR, o arquivo local não está no diretório de recursos de aplicativos; tais arquivos são colocados na área de segurança. O arquivo pode ler de fontes de dados locais mas não pode se comunicar com a Internet.

Elementos da API relacionados

O arquivo SWF é um arquivo local, não foi confiado pelo usuário e é um arquivo SWF publicado com uma designação de rede. O arquivo pode se comunicar com a Internet mas não pode ler de fontes de dados locais.

Elementos da API relacionados

O arquivo é proveniente de uma URL da Internet e opera de acordo com as regras da caixa de proteção com base em domínio.

Elementos da API relacionados