Security  - AS3

Determina il modo in cui Flash Player o AIR sceglie il dominio da utilizzare per alcune impostazioni, fra cui le autorizzazioni relative a videocamere e microfoni, le quote di archiviazione e l'archiviazione di oggetti condivisi persistenti. Per fare in modo che il file SWF utilizzi le stesse impostazioni usate in Flash Player 6, impostate exactSettings su false.

In Flash Player 6, il dominio utilizzato per queste impostazioni del lettore si basava sulla porzione finale del dominio del file SWF. Se il dominio di un file SWF include più di due segmenti, come www.example.com, il primo segmento ("www") viene rimosso e viene utilizzata la porzione restante del dominio: example.com. Quindi, in Flash Player 6, www.example.com e store.example.com utilizzano entrambi example.com come dominio per queste impostazioni. Allo stesso modo, www.example.co.uk e store.example.co.uk utilizzano entrambi example.co.uk come dominio per le impostazioni. In Flash Player 7 e versioni successive, le impostazioni del lettore vengono scelte per impostazione predefinita in base al dominio esatto di un file SWF. Ad esempio, un file SWF di www.example.com utilizzerebbe le impostazioni del lettore relative a www.example.com, e un file SWF di store.example.com le impostazioni separate relative a store.example.com.

Quando Security.exactSettings è impostata su true, Flash Player o AIR utilizza i domini esatti per le impostazioni del lettore. Il valore predefinito di exactSettings è true. Se modificate il valore predefinito di exactSettings, eseguite la modifica prima che si verifichi qualsiasi evento che richieda la scelta delle impostazioni del lettore da parte di Flash Player o AIR, ad esempio l'uso della videocamera e del microfono o il recupero di un oggetto condiviso persistente.

Se in precedenza avevate pubblicato un file SWF di versione 6 da cui avevate creato oggetti condivisi persistenti e ora desiderate recuperare tali oggetti da quel file SWF dopo averne eseguito il porting alla versione 7 o successiva, oppure da un altro file SWF della versione 7 o successiva, impostate Security.exactSettings su false prima di chiamare SharedObject.getLocal().

La porzione del dominio della pagina HTML che contiene il file SWF.

Per motivi di sicurezza, questo metodo non restituisce l'URL completo bensì solo il dominio di pagina, ad esempio http://www.example.com. Se questo SWF non è contenuto in una pagina HTML oppure non può accedere al dominio di pagina per motivi di sicurezza, questa proprietà restituisce la stringa undefined.

Indica il tipo di sandbox di sicurezza in cui opera il file chiamante.

Security.sandboxType può assumere uno dei seguenti valori:

• remote (Security.REMOTE): questo file deriva da un URL Internet e viene gestito tramite regole sandbox basate sul dominio.
• localWithFile (Security.LOCAL_WITH_FILE): file locale che non è considerato affidabile dall'utente e non è un file SWF che è stato pubblicato con una designazione di rete. Il file può leggere le origini dati locali, ma non può comunicare con Internet.
• localWithNetwork (Security.LOCAL_WITH_NETWORK): questo file SWF è un file locale che non è considerato affidabile dall'utente ed è stato pubblicato con una designazione di rete. Il file SWF può comunicare con Internet ma non può leggere da origini dati locali.
• localTrusted (Security.LOCAL_TRUSTED): questo file è un file locale che è stato considerato affidabile dall'utente tramite Gestione impostazioni di Flash Player o il file di configurazione FlashPlayerTrust. Il file può leggere le origini dati locali e comunicare con Internet.
• application (Security.APPLICATION): questo file è in esecuzione in un'applicazione AIR ed è stato installato con il pacchetto (file AIR) per tale applicazione. Per impostazione predefinita, i file nella sandbox dell'applicazione AIR possono eseguire scambi di script con file di qualsiasi dominio (anche se i file al di fuori della sandbox dell'applicazione AIR possono non essere autorizzati a effettuare scambi di script con il file AIR). Per impostazione predefinita, i file nella sandbox dell'applicazione AIR possono caricare contenuto e dati da qualsiasi dominio.

Per ulteriori informazioni sulla sicurezza, vedete l'argomento sulla sicurezza nel Centro per sviluppatori di Flash Player .

Altri esempi

Elementi API correlati

Consente ai file SWF dei domini identificati di accedere agli oggetti e alle variabili presenti nel file SWF che contiene la chiamata allowDomain().

Nota: se si chiama questo metodo da codice contenuto nella sandbox di sicurezza dell'applicazione AIR, viene generata un'eccezione SecurityError. Il contenuto al di fuori del dominio di sicurezza dell'applicazione non può effettuare scambi di script diretti con contenuto che si trova nella sandbox dell'applicazione. Tuttavia, il contenuto al di fuori della sandbox dell'applicazione può comunicare con contenuto che si trova nella sandbox di sicurezza dell'applicazione mediante un bridge sandbox.

Se due file SWF appartengono allo stesso dominio, ad esempio http://mysite.com/swfA.swf e http://mysite.com/swfB.swf, mediante swfA.swf è possibile esaminare e modificare variabili, oggetti, proprietà, metodi e così via in swfB.swf, e mediante swfB.swf è possibile procedere allo stesso modo per swfA.swf. Questa operazione è detta scambio di script tra filmati, o scambio di script.

Se due file SWF appartengono a domini diversi, ad esempio http://siteA.com/swfA.swf e http://siteB.com/siteB.swf, per impostazione predefinita non è consentito a swfA.swf di eseguire script su swfB.swf né viceversa. Un file SWF concede l'autorizzazione ai file SWF di altri domini tramite la chiamata alla funzione Security.allowDomain(). Questa operazione è detta scambio di script tra domini. La chiamata a Security.allowDomain("siteA.com") permette a siteB.swf di autorizzare siteA.swf a scambiare script con siteB.swf.

In qualsiasi configurazione tra domini, sono coinvolte due parti ed è importante chiarire il ruolo di ognuna. Ai fini di questa discussione, il lato che esegue lo scambio di script è detto parte che accede (di solito il SWF che esegue l'accesso), mentre l'altro lato è detto parte a cui si accede (di solito il file SWF a cui si accede). Quando siteA.swf invia script a siteB.swf, siteA.swf è la parte che accede, mentre siteB.swf la parte a cui si accede.

Le autorizzazioni tra domini definite tramite allowDomain() sono asimmetriche. Nell'esempio precedente, siteA.swf può inviare script a siteB.swf, ma siteB.swf non può inviare script a siteA.swf, poiché siteA.swf non ha eseguito la chiamata a allowDomain() per dare ai file SWF di siteB.com l'autorizzazione a inviargli script. È possibile impostare autorizzazioni simmetriche facendo in modo che entrambi i file eseguano una chiamata a allowDomain().

Oltre a proteggere i file SWF dall'esecuzione di script tra domini generati da altri file SWF, Flash Player protegge i file SWF dall'esecuzione di script tra domini generati da file HTML. Lo scambio di script tra file HTML e SWF può essere effettuato con le funzioni del browser Flash più vecchie quali SetVariable oppure mediante la chiamata di funzioni di callback definite tramite ExternalInterface.addCallback(). Quando gli script da HTML a SWF superano il dominio, il file SWF a cui si accede deve chiamare allowDomain(), esattamente come quando la parte che accede è un file SWF; in caso contrario, l'operazione non viene completata.

Se si specifica un indirizzo IP come parametro di allowDomain(), non viene consentito l'accesso a tutte le parti che accedono dall'indirizzo IP specificato. Al contrario, viene consentito solo l'accesso da una parte che contiene l'indirizzo IP specificato nel proprio URL, anziché il nome di dominio mappato sull'indirizzo IP.

Differenze specifiche della versione

Le regole di protezione tra domini di Flash Player sono state modificate da una versione all'altra. Nella tabella seguente sono riepilogate le differenze.

Le versioni che controllano il comportamento di Flash Player sono versioni di SWF (la versione pubblicata di un file SWF), non la versione stessa di Flash Player. Quando, ad esempio, Flash Player 8 riproduce un file SWF pubblicato per la versione 7, viene applicato un comportamento conforme alla versione 7. In questo modo, viene garantito che gli aggiornamenti del lettore non modificano il comportamento di Security.allowDomain() nei file SWF distribuiti.

La colonna della versione presente nella tabella precedente si riferisce alla versione di SWF più recente coinvolta in un'operazione di scambio di script. Flash Player determina il proprio comportamento in base alla versione del file SWF che accede oppure alla versione del file SWF a cui si accede, a seconda della versione più recente.

I paragrafi che seguono forniscono informazioni più dettagliate sulle modifiche relative alla sicurezza di Flash Player che riguardano Security.allowDomain().

Versione 5. Nessuna restrizione per script tra domini.

Versione 6. Viene introdotta la sicurezza relativa agli script tra domini. Per impostazione predefinita, Flash Player non consente lo scambio di script tra domini; con Security.allowDomain() è possibile abilitarlo. Per determinare se due file si trovano nello stesso dominio, viene utilizzato il superdominio di ogni file, che corrisponde esattamente al nome host contenuto nell'URL, meno il primo segmento, fino a un minimo di due segmenti. Ad esempio, il superdominio di www.mysite.com è semplicemente mysite.com, che consentirebbe ai file SWF di www.mysite.com e store.mysite.com di eseguire script reciprocamente senza chiamare Security.allowDomain().

Versione 7. La corrispondenza del superdominio viene modificata in corrispondenza esatta del dominio. A due file è consentito solo eseguire script reciprocamente se i nomi host nei relativi URL sono identici; in caso contrario è necessaria una chiamata a Security.allowDomain(). Per impostazione predefinita, ai file caricati da URL non di tipo HTTPS non è più consentito eseguire script su file caricati da URL HTTPS, anche se i file vengono caricati dallo stesso esatto dominio. Questa restrizione contribuisce a proteggere i file HTTPS, in quanto un file non di tipo HTTPS è soggetto a modifica durante lo scaricamento e un file non HTTPS modificato appositamente potrebbe danneggiare un file HTTPS che, diversamente, non è esposto a manipolazioni. Security.allowInsecureDomain() è stato introdotto per permettere ai file SWF HTTPS a cui si accede di disabilitare direttamente questa limitazione, anche se Adobe sconsiglia di usare Security.allowInsecureDomain().

Versione 8. Due aree di modifica principali:

• La chiamata di Security.allowDomain() permette ora di effettuare operazioni di scambio di script solo se il file SWF a cui si accede è quello che ha chiamato Security.allowDomain(). In altre parole, un file SWF che chiama Security.allowDomain() permette l'accesso solo a se stesso. Nelle versioni precedenti la chiamata di Security.allowDomain() permetteva operazioni di scambio di script, in cui il file SWF a cui si accedeva poteva essere qualsiasi file SWF dello stesso dominio del file SWF che chiamava Security.allowDomain(). Nelle versioni precedenti la chiamata di Security.allowDomain() apriva tutto il dominio del file SWF chiamante.
• La nuova versione consente di usare i valori dei caratteri jolly per Security.allowDomain("*") e Security.allowInsecureDomain("*"). Il valore carattere jolly (*) consente operazioni di scambio di script in cui il file che accede corrisponde a qualsiasi file caricato da qualsiasi area. Un carattere jolly può essere paragonato a un'autorizzazione globale. Queste autorizzazioni sono necessarie per abilitare alcuni tipi di operazioni in base alle regole di sicurezza per i file locali. Più precisamente, perché un file SWF locale fornito di autorizzazioni di accesso alla rete, possa accedere a un file SWF su Internet, quest'ultimo deve eseguire una chiamata a Security.allowDomain("*"), in modo da riflettere il fatto che l'origine del file SWF locale è sconosciuta. Se il file SWF a cui si accede su Internet viene caricato da un URL HTTPS, quel file dovrà invece chiamare Security.allowInsecureDomain("*").

Talvolta può verificarsi la situazione seguente: si carica un file SWF secondario da un dominio diverso e si desidera consentirgli di attivare uno script nel file SWF principale, ma non si conosce il dominio finale del file SWF secondario. Questa situazione può verificarsi ad esempio quando si utilizzano i reindirizzamenti per il bilanciamento del carico di lavoro o i server di terze parti.

In questi casi, è possibile utilizzare la proprietà url dell'oggetto URLRequest che viene passato a Loader.load(). Ad esempio, se si carica un file SWF secondario in un file SWF principale, è possibile accedere alla proprietà contentLoaderInfo dell'oggetto Loader per il file SWF principale:

Security.allowDomain(loader.contentLoaderInfo.url)

Attendere che il file SWF secondario inizi il caricamento per ottenere il valore esatto della proprietà url. Per determinare il momento in cui il file SWF ha iniziato il caricamento, utilizzate l'evento progress.

In realtà può verificarsi anche la situazione opposta: è possibile creare un file SWF secondario impostato per accettare gli script eseguiti dal proprio elemento principale ma di cui non conosce il dominio. In questo caso, è possibile accedere alla proprietà loaderInfo dell'oggetto visualizzato, che è l'oggetto radice del file SWF. Nel file SWF secondario, chiamate Security.allowDomain( this.root.loaderInfo.loaderURL). Non è necessario attendere il caricamento del file SWF principale poiché sarà già stato completato al momento del caricamento dell'elemento secondario.

Se pubblicate contenuto per Flash Player 8 o versione successiva, è possibile gestire queste situazioni anche chiamando Security.allowDomain("*"). Questa soluzione può tuttavia risultare rischiosa, poiché consente l'accesso al file SWF chiamante da qualsiasi altro SWF in qualsiasi dominio. Generalmente è più sicuro usare la proprietà _url.

Per ulteriori informazioni sulla sicurezza, vedete l'argomento sulla sicurezza nel Centro per sviluppatori di Flash Player .

Parametri

Altri esempi

Elementi API correlati

Consente ai file SWF e HTML dei domini identificati di accedere agli oggetti e alle variabili presenti nel file SWF chiamante, che risiede sul dominio mediante il protocollo HTTPS.

Flash Player fornisce allowInsecureDomain() per massimizzare la flessibilità, sebbene la chiamata a questo metodo sia un'operazione sconsigliata. L'accesso a un file mediante HTTPS offre numerose misure di protezione a livello generale, una delle quali viene limitata con la chiamata ad allowInsecureDomain.

Nota: se si chiama questo metodo da codice contenuto nella sandbox di sicurezza dell'applicazione AIR, viene generata un'eccezione SecurityError. Il contenuto al di fuori del dominio di sicurezza dell'applicazione non può effettuare scambi di script diretti con contenuto che si trova nella sandbox dell'applicazione. Tuttavia, il contenuto al di fuori della sandbox dell'applicazione può comunicare con contenuto che si trova nella sandbox di sicurezza dell'applicazione mediante un bridge sandbox.

Questo metodo presenta lo stesso funzionamento di Security.allowDomain(), ma consente anche operazioni nelle quali la parte che accede viene caricata con un protocollo non HTTPS, mentre la parte a cui si accede viene caricata mediante HTTPS. In Flash Player 7 e versioni successive, ai file non di tipo HTTPS non è consentito eseguire script su file HTTPS. Il metodo allowInsecureDomain(), se utilizzato dal file SWF HTTP a cui si accede, elimina questa restrizione.

Utilizzate allowInsecureDomain() solo per consentire l'esecuzione di script da file non HTTPS a file HTTPS. Utilizzate questo metodo per consentire l'esecuzione di script quando il file non HTTPS che accede e il file HTTPS a cui si accede risiedono nello stesso dominio, ad esempio se un file SWF in http://mysite.com deve eseguire script su https://mysite.com. Non utilizzare questo metodo per consentire l'esecuzione di script tra file non HTTPS, tra file HTTPS oppure da file HTTPS a file non HTTPS. In queste situazioni utilizzare allowDomain().

Tenere presente che le informazioni seguenti si riferiscono solo a un possibile scenario e vengono fornite per comprendere meglio allowInsecureDomain() attraverso un esempio reale di scambio di script. Non vengono trattate tutte le problematiche dell'architettura di sicurezza, pertanto queste informazioni devono essere utilizzate solo come concetti di base. Nel Centro per sviluppatori Flash Player sono disponibili ampie informazioni su Flash Player e sulla sicurezza. Per ulteriori informazioni, vedete l'argomento sicurezza nel Centro per sviluppatori di Flash Player .

Supponete di dover creare un sito di e-commerce costituito da due componenti: un catalogo, che non deve essere protetto poiché contiene solo informazioni pubbliche, e un componente carrello/modulo di pagamento, che deve essere protetto per assicurare la riservatezza delle informazioni finanziarie e personali degli utenti. Supponete di voler creare il catalogo da http://mysite.com/catalog.swf e il carrello da https://mysite.com/cart.swf. Uno dei requisiti del sito è sicuramente la necessità di impedire a terzi di impossessarsi dei dati delle carte di credito degli utenti sfruttando una qualsiasi debolezza nell'architettura di sicurezza.

Supponete che un utente malintenzionato si inserisca tra il server e gli utenti per cercare di sottrarre i numeri di carta di credito immessi dagli utenti nell'applicazione per gli acquisti. Questo utente malintenzionato può essere, ad esempio, un ISP poco scrupoloso utilizzato da alcuni dei vostri utenti oppure un amministratore nell'area di lavoro di un utente, ovvero chiunque abbia la capacità di visualizzare o alterare pacchetti di rete trasmessi attraverso Internet tra i vostri utenti e i vostri server. Questa situazione è piuttosto comune.

Se cart.swf utilizza HTTPS per trasmettere informazioni sulle carte di credito ai server, l'utente malintenzionato non può accedere direttamente a queste informazioni dai pacchetti di rete, in quanto la trasmissione mediante HTTPS è crittografata. Chi effettua l'attacco può, tuttavia, usare una tecnica diversa: alterare il contenuto di uno dei file SWF presentati all'utente e sostituire questo file con una versione modificata che trasmette le informazioni dell'utente a un server diverso di proprietà dell'utente malintenzionato.

Il protocollo HTTPS impedisce, tra l'altro, questo tipo di "attacco mediante modifica", poiché oltre a essere crittografate, le trasmissioni HTTPS non sono soggette a manomissioni: se un utente malintenzionato altera un pacchetto, la parte ricevente rileva la modifica e scarta il pacchetto. In questo caso il file cart.swf non può essere modificato, essendo distribuito tramite HTTPS.

Supponete di voler consentire l'aggiunta di articoli al carrello nel file cart.swf, a cui si accede tramite HTTPS, mediante i pulsanti contenuti nel file catalog.swf, a cui si accede tramite HTTPS. A questo scopo cart.swf chiama allowInsecureDomain(), che consente al file catalog.swf di eseguire script su cart.swf. Questa azione ha tuttavia una conseguenza indesiderata: ora l'utente malintenzionato può modificare catalog.swf, che viene scaricato inizialmente dall'utente, in quanto questo file viene distribuito mediante HTTP ed è soggetto a manomissioni. Il file catalog.swf alterato dall'utente malintenzionato può eseguire script su cart.swf, poiché cart.swf contiene una chiamata a allowInsecureDomain(). Il file catalog.swf alterato può utilizzare codice ActionScript per accedere alle variabili in cart.swf e, di conseguenza, leggere le informazioni relative alla carta di credito e altri dati riservati dell'utente. Il file catalog.swf alterato può quindi inviare questi dati al server dell'utente malintenzionato.

Naturalmente, questa implementazione non è auspicabile, ma sarebbe comunque opportuno consentire lo scambio di script tra i due file SWF del sito. Di seguito sono riportati due possibili metodi per riprogettare questo ipotetico sito di e-commerce in modo da evitare la chiamata ad allowInsecureDomain():

• Consentire l'accesso a tutti i file SWF nell'applicazione mediante HTTPS. Questa è sicuramente la soluzione più semplice e affidabile. Nello scenario descritto si consente quindi l'accesso a catalog.swf e a cart.swf mediante HTTPS. È possibile che, nel passaggio di un file come catalog.swf da HTTP a HTTPS, si verifichi un consumo dell'ampiezza di banda leggermente superiore e un carico maggiore della CPU del server e che, inoltre, il caricamento dell'applicazione per gli utenti richieda più tempo. È necessario effettuare delle prove con server reali per determinare l'incidenza di questi effetti; di solito il peggioramento non supera, per ognuno, il 10-20% e a volte è assente del tutto. Generalmente è possibile ottenere risultati migliori installando acceleratori hardware o software per HTTPS sui server. Uno dei principali vantaggi della configurazione dell'accesso a tutti i file SWF di un sito mediante HTTPS, consiste nella possibilità di utilizzare un URL HTTPS come URL principale nel browser dell'utente, senza che il browser generi avvisi relativi alla presenza di contenuto misto. Nel browser viene inoltre visualizzata un'icona di lucchetto, che fornisce agli utenti un'indicazione di sicurezza comune e affidabile.
• Utilizzate script da HTTPS a HTTP anziché da HTTP a HTTPS. Nello scenario descritto, è possibile memorizzare il contenuto del carrello dell'utente nel file catalog.swf e fare in modo che cart.swf gestisca solo il processo di pagamento. Al momento del checkout cart.swf può recuperare il contenuto del carrello dalle variabili di ActionScript nel file catalog.swf. La limitazione sullo scambio di script da HTTP a HTTPS è simmetrica. Tuttavia, sebbene non sia possibile verificare che un file catalog.swf distribuito da HTTP invii uno script sicuro a un file cart.swf distribuito da HTTPS, un file cart.swf HTTPS può inviare uno script al file catalog.swf HTTP. Questo approccio è più sensibile rispetto all'approccio a tutti i file HTTPS, ma occorre fare attenzione a non considerare affidabili i file SWF distribuiti da HTTP poiché possono essere stati modificati. Quando, ad esempio, cart.swf recupera la variabile di ActionScript che descrive il contenuto del carrello, il codice ActionScript presente nel file cart.swf non può assicurare che il valore di questa variabile sia nel formato previsto. È necessario verificare che nel contenuto del carrello non siano presenti dati non validi che potrebbero indurre all'esecuzione di un'azione indesiderata da parte di cart.swf. È inoltre necessario accettare il rischio che un utente malintenzionato, mediante la modifica di catalog.swf, fornisca dati validi ma non precisi a cart.swf, ad esempio inserendo nel carrello articoli dell'utente. Il normale processo di pagamento limita, in qualche modo, questo rischio con la visualizzazione del contenuto del carrello e del costo totale per l'approvazione finale da parte dell'utente, tuttavia il rischio è presente.

Da anni, i browser Web applicano una separazione tra HTTPS e non HTTPS, e lo scenario descritto giustifica questa limitazione. Flash Player offre una soluzione alternativa a questa limitazione della sicurezza, quando è assolutamente necessario, tuttavia prima di procedere in questo senso è opportuno considerare attentamente le conseguenze.

Per ulteriori informazioni sulla sicurezza, vedete l'argomento sulla sicurezza nel Centro per sviluppatori di Flash Player .

Parametri

Elementi API correlati

Cerca un file di criteri validi in una posizione specificata dal parametro url. Adobe AIR e Flash Player utilizzano file dei criteri per determinare se autorizzare le applicazioni a caricare dati da server diversi da quello su cui risiedono. Sebbene il nome del metodo sia loadPolicyFile(), il file non viene realmente caricato finché non si effettua una richiesta di rete per il file dei criteri.

Grazie a Security.loadPolicyFile(), Flash Player o AIR è in grado di caricare i file dei criteri da posizioni arbitrarie, come nell'esempio seguente:

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

In questo modo Flash Player o AIR tenta di recuperare un file dei criteri dall'URL specificato. Qualsiasi autorizzazione concessa dal file dei criteri in quella posizione viene applicata a tutto il contenuto che si trova nello stesso livello o a un livello inferiore nella gerarchia di directory virtuale del server.

Ad esempio, se si segue il codice precedente, queste righe non generano un'eccezione:

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

Al contrario, il codice seguente genera un'eccezione di sicurezza:

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

È possibile utilizzare loadPolicyFile() per caricare un numero qualsiasi di file dei criteri di sicurezza. Nel caso di una richiesta che prevede un file dei criteri, Flash Player o AIR attende sempre il completamento del caricamento dei file dei criteri prima di negare l'autorizzazione a una richiesta. In ultima analisi, se nessun file dei criteri specificato tramite loadPolicyFile() autorizza una richiesta, Flash Player o AIR consulta le posizioni predefinite originali.

Durante la ricerca di un file di criteri principale, Flash Player attende per tre secondi una risposta dal server. Se non riceve risposta, Flash Player deduce che il file di criteri principale non esiste. Non vi è tuttavia un timeout predefinito per le chiamate a loadPolicyFile(). Flash Player presuppone che il file chiamato esiste e attende tutto il tempo necessario per caricarlo. Quindi, per essere certi che il file di criteri principale venga caricato, usate loadPolicyFile() per chiamarlo esplicitamente.

Non potete collegarvi alle porte comunemente riservate. Per un elenco completo di porte bloccate, vedete "Limitazioni delle API di connettività di rete" nella Guida per gli sviluppatori di ActionScript 3.0.

L'uso del protocollo xmlsocket insieme a un numero di porta specifico consente di recuperare i file dei criteri direttamente da un server XMLSocket, come nell'esempio seguente. Le connessioni socket non sono soggette alle restrizioni relative alle porte riservate sopra descritte.

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

In questo modo Flash Player o AIR cerca di recuperare un file dei criteri dall'host e dalla porta specificati. Dopo aver stabilito una connessione con la porta specificata, Flash Player o AIR trasmette il comando <policy-file-request />, terminato da un byte null. Il server deve inviare un byte nullo per terminare un file dei criteri e, successivamente, chiudere la connessione. Se il server non chiude la connessione, questa viene chiusa da Flash Player o AIR dopo aver ricevuto il byte null di terminazione.

È possibile impedire che un file SWF utilizzi questo metodo impostando il parametro allowNetworking dei tag object e embed nella pagina HTML che include il contenuto SWF.

Per ulteriori informazioni sulla sicurezza, vedete l'argomento sulla sicurezza nel Centro per sviluppatori di Flash Player .

Parametri

Altri esempi

Visualizza il pannello Impostazioni di sicurezza in Flash Player. Questo metodo non è applicabile a contenuto in Adobe AIR; se lo si chiama in un'applicazione AIR non si otterrà alcun effetto.

Parametri

Elementi API correlati

Il file in esecuzione in un'applicazione AIR e installato con il pacchetto (il file AIR) per quell'applicazione. Questo contenuto è incluso nella directory delle risorse dell'applicazione AIR (dove è installato il contenuto dell'applicazione).

Elementi API correlati

Il file è un file locale che è stato considerato affidabile dall'utente tramite Gestione impostazioni Flash Player o il file di configurazione FlashPlayerTrust. Il file può leggere le origini dati locali e comunicare con Internet.

Elementi API correlati

Il file è un file locale che non è considerato affidabile dall'utente e non è un file SWF che è stato pubblicato con una designazione di rete. In Adobe AIR, il file locale non si trova nella directory delle risorse dell'applicazione; questi file vengono inseriti nella sandbox di sicurezza dell'applicazione. Il file può leggere le origini dati locali, ma non può comunicare con Internet.

Elementi API correlati

Il file è un file locale che non è considerato affidabile dall'utente ed è un file SWF che è stato pubblicato con una designazione di rete. Il file può comunicare con Internet ma non può leggere da origini dati locali.

Elementi API correlati

Il file deriva da un URL Internet e viene gestito tramite regole sandbox basate su dominio.

Elementi API correlati