Security  - AS3

Bepaalt hoe Flash Player of AIR het domein kiest dat moet worden gebruikt voor bepaalde inhoudsinstellingen, inclusief instellingen voor camera- en microfoonmachtigingen, opslagquota's en opslag van blijvende gezamenlijke objecten. Stel exactSettings in op false om te zorgen dat het SWF-bestand dezelfde instellingen gebruikt als de instellingen die in Flash Player 6 werden gebruikt.

In Flash Player 6 was het domein dat voor deze Player-instellingen werd gebruikt, gebaseerd op het laatste gedeelte van het domein van het SWF-bestand. Wanneer het domein van een SWF-bestand uit meer dan twee segmenten bestaat, bijvoorbeeld www.example.com, wordt het eerste segment van het domein (www) verwijderd en wordt het resterende gedeelte van het domein gebruikt: example.com. In Flash Player 6 wordt example.com dus zowel door www.example.com als store.example.com gebruikt als het domein voor deze instellingen. Ook www.example.co.nl en store.example.co.nl gebruiken beide example.co.nl als het domein voor deze instellingen. In Flash Player 7 en hoger worden de Player-instellingen standaard gekozen overeenkomstig het exacte domein van een SWF-bestand: een SWF-bestand dat bijvoorbeeld afkomstig is van www.example.com, gebruikt de Player-instellingen van www.example.com en een SWF-bestand dat afkomstig is van store.example.com, gebruikt de Player-instellingen van store.example.com.

Als Security.exactSettings is ingesteld op true, gebruikt Flash Player of AIR exacte domeinen voor spelerinstellingen. De standaardwaarde van exactSettings is true. Als u een andere waarde dan de standaardwaarde wilt instellen voor exactSettings, moet u dit doen voordat er gebeurtenissen optreden die vereisen dat Flash Player of AIR spelerinstellingen selecteert, bijvoorbeeld als u een camera of microfoon gebruikt of als u een permanent gedeeld object ophaalt.

Wanneer u eerder een SWF-bestand voor versie 6 hebt gepubliceerd en hieruit permanente gedeelde objecten hebt gegenereerd, en als u deze permanente gedeelde objecten nu uit dat SWF-bestand wilt ophalen nadat u het bestand naar versie 7 of hoger hebt overgezet, of uit een ander SWF-bestand van versie 7 of hoger, moet u Security.exactSettings op false instellen voordat u SharedObject.getLocal() aanroept.

Het domeingedeelte van de HTML-pagina met het SWF-bestand.

Om beveiligingsredenen wordt bij deze methode niet de volledige URL geretourneerd, maar alleen het paginadomein zoals http://www.example.com. Als dit SWF-bestand om beveiligingsredenen niet in een HTML-pagina is opgenomen of geen toegang heeft tot het paginadomein, retourneert deze eigenschap de tekenreeks undefined.

Hiermee wordt het type beveiligingssandbox aangegeven waarin het aanroepende bestand wordt uitgevoerd.

Security.sandboxType heeft een van de volgende waarden:

• remote (Security.REMOTE) - Het bestand is afkomstig van een internet-URL en wordt uitgevoerd volgens op domein gebaseerde sandboxregels.
• localWithFile (Security.LOCAL_WITH_FILE) - Het bestand is een lokaal bestand dat niet door de gebruiker als vertrouwd is opgegeven en is niet een SWF-bestand dat met een netwerkbestemming is gepubliceerd. Het bestand kan informatie van lokale gegevensbronnen lezen, maar kan niet met internet communiceren.
• localWithNetwork (Security.LOCAL_WITH_NETWORK) - Het SWF-bestand is een lokaal bestand dat niet door de gebruiker als vertrouwd is opgegeven, maar wel is gepubliceerd met een netwerkbestemming. Het SWF-bestand kan met internet communiceren maar kan geen informatie lezen van lokale gegevensbronnen.
• localTrusted (Security.LOCAL_TRUSTED) - Het bestand is een lokaal bestand dat door de gebruiker als vertrouwd is opgegeven via Settings Manager van Flash Player of een configuratiebestand in de map FlashPlayerTrust. Het bestand kan informatie lezen van lokale gegevensbronnen en kan met internet communiceren.
• application (Security.APPLICATION)— Het bestand wordt uitgevoerd in een AIR-toepassing en is geïnstalleerd met het pakket (AIR-bestand) voor die toepassing. Standaard kunnen bestanden in de sandbox van de AIR-toepassing vanuit elk domein cross-scripting uitvoeren op elk bestand (hoewel bestanden buiten de sandbox van de AIR-toepassing mogelijk geen toestemming hebben om cross-scripting uit te voeren in het AIR-bestand). Standaard kunnen bestanden in de sandbox van de AIR-toepassing inhoud en gegevens laden vanuit elk gewenst domein.

Lees voor meer informatie over beveiliging het onderwerp Security in het Flash Player Developer Center.

Verwante API-elementen

Geeft SWF-bestanden in de opgegeven domeinen toegang tot objecten en variabelen in het SWF-bestand dat de oproep allowDomain() bevat.

Opmerking: Als deze methode wordt aangeroepen vanuit code in de beveiligingssandbox van de AIR-toepassing, wordt er een SecurityError-uitzondering gegenereerd. Inhoud van buiten het beveiligingsdomein van de toepassing kan niet rechtstreeks cross-scripting uitvoeren op inhoud binnen de beveiligingssandbox. Inhoud buiten de sandbox van de toepassing kan echter met behulp van een sandboxbridge wel communiceren met inhoud binnen de beveiligingssandbox van de toepassing.

Als twee SWF-bestanden op hetzelfde domein staan, bijvoorbeeld http://mysite.com/swfA.swf en http://mysite.com/swfB.swf, dan kan swfA.swf variabelen, objecten, eigenschappen, methoden, enzovoort in swfB.swf lezen en wijzigen en vice versa. Dit wordt cross-scripting genoemd.

Als twee SWF-bestanden op verschillende domeinen staan, bijvoorbeeld http://siteA.com/swfA.swf en http://siteB.com/siteB.swf, dan staat Flash Player standaard geen cross-scripting toe van swfA.swf naar swfB.swf en vice versa. Een SWF-bestand geeft toestemming aan SWF-bestanden in andere domeinen door Security.allowDomain() aan te roepen. Dit wordt interdomein-scripting genoemd. Door Security.allowDomain('siteA.com') aan te roepen, geeft siteB.swf toestemming aan siteA.swf om scriptbewerkingen uit te voeren op siteB.swf.

In elke interdomeinsituatie is het belangrijk om duidelijk te zijn over de rol van de twee betrokken partijen. De partij die cross-scripting uitvoert, wordt de benaderende partij genoemd (doorgaans het benaderende SWF-bestand) en de andere partij wordt de benaderde partij genoemd (doorgaans het SWF-bestand dat wordt geopend). Wanneer siteA.swf scriptbewerkingen uitvoert op siteB.swf, is siteA.swf de benaderende partij en siteB.swf de benaderde partij.

Interdomeinbevoegdheden die met allowDomain() worden ingesteld, zijn asymmetrisch. In het vorige voorbeeld kan siteA.swf scriptbewerkingen uitvoeren op siteB.swf, maar niet andersom, omdat siteA.swf allowDomain() niet heeft aangeroepen om SWF-bestanden op siteB.com toestemming te geven scriptbewerkingen op siteA.swf uit te voeren. U kunt symmetrische bevoegdheden instellen door beide SWF-bestanden allowDomain() te laten aanroepen.

Naast het beveiligen van SWF-bestanden tegen interdomein-scripting door andere SWF-bestanden, beveiligt Flash Player SWF-bestanden tegen interdomein-scripting door HTML-bestanden. HTML-naar-SWF-scriptbewerkingen kunnen optreden met oudere browserfuncties zoals SetVariable of met callbacks via ExternalInterface.addCallback(). Wanneer HTML-naar-SWF-scriptbewerkingen in verschillende domeinen worden uitgevoerd, moet het SWF-bestand dat wordt benaderd allowDomain() aanroepen, net als wanneer de benaderende partij een SWF-bestand is, anders mislukt de bewerking.

Wanneer een IP-adres wordt opgegeven als een parameter voor allowDomain(), betekent dit niet dat alle partijen afkomstig van het opgegeven IP-adres toegang hebben. Alleen een partij waarvan het IP-adres specifiek in de URL is opgegeven krijgt toegang, niet een domeinnaam die aan dat IP-adres is toegewezen.

Versiespecifieke verschillen

De regels voor interdomeinbeveiliging van Flash Player zijn van versie tot versie geëvolueerd. De volgende tabel geeft een overzicht van de verschillen.

Het gedrag van Flash Player wordt bepaald door de SWF-versies (de gepubliceerde versie van een SWF-bestand), niet de versie van Flash Player zelf. Wanneer in Flash Player 8 bijvoorbeeld een SWF-bestand wordt afgespeeld dat voor versie 7 is gepubliceerd, gedraagt het programma zich zoals u zou verwachten van versie 7. Dit zorgt ervoor dat upgrades van de speler het gedrag van Security.allowDomain() in geïmplementeerde SWF-bestanden niet wijzigen.

In de versiekolom in de vorige tabel wordt aangegeven welke meest recente SWF-versie in een cross-scriptingbewerking is gebruikt. Flash Player bepaalt het gedrag op basis van de versie van het benaderende SWF-bestand of de versie van het SWF-bestand dat wordt benaderd, afhankelijk van welke versie het meest recent is.

De volgende alinea's bevatten meer informatie over wijzigingen in de beveiliging van Flash Player met betrekking tot Security.allowDomain().

Versie 5. Er gelden geen beperkingen voor interdomein-scripting.

Versie 6. In deze versie is voor het eerst beveiliging voor interdomein-scripting opgenomen. Standaard is interdomein-scripting niet toegestaan in Flash Player. Met Security.allowDomain() kan het wel worden toegestaan. Flash Player gebruikt het superdomein van elk bestand om te bepalen of twee bestanden zich in hetzelfde domein bevinden. Het superdomein is de exacte hostnaam uit de URL van het bestand, min het eerste segment (minimaal twee segmenten). Het superdomein van www.mysite.com is bijvoorbeeld mysite.com. SWF-bestanden van www.mysite.com en store.mysite.com kunnen scriptbewerkingen op elkaar uitvoeren zonder Security.allowDomain() aan te roepen.

Versie 7. In plaats van superdomeinovereenkomsten worden exacte domeinovereenkomsten gebruikt. Twee bestanden kunnen alleen scriptbewerkingen op elkaar uitvoeren wanneer de hostnamen in de URL's identiek zijn, anders moet Security.allowDomain() worden aangeroepen. Standaard kunnen bestanden die via niet-HTTP-URL's zijn geladen geen scriptbewerkingen meer uitvoeren op bestanden die via HTTP-URL's zijn geladen, ook niet wanneer de bestanden via exact hetzelfde domein worden geladen. Dankzij deze beperking kunnen HTTPS-bestanden worden beveiligd, omdat een niet-HTTPS-bestand tijdens downloadbewerkingen kwetsbaar is voor wijzigingen en een door een kwaadwillende gebruiker gewijzigd niet-HTTPS-bestand een HTTPS-bestand kan beschadigen dat verder niet kwetsbaar is voor dergelijke bewerkingen. Security.allowInsecureDomain() is geïntroduceerd zodat benaderde HTTPS SWF-bestanden deze beperking kunnen uitschakelen, maar het gebruik van Security.allowInsecureDomain() wordt afgeraden.

Versie 8. Er zijn twee belangrijke wijzigingen:

• Wanneer Security.allowDomain() wordt aangeroepen, zijn cross-scriptingbewerkingen nu alleen toegestaan wanneer het benaderde SWF-bestand het SWF-bestand is dat Security.allowDomain() heeft aangeroepen. Met andere woorden, een SWF-bestand dat Security.allowDomain() aanroept, staat nu alleen toegang tot zichzelf toe. In eerdere versies kon bij cross-scriptingbewerkingen waarbij Security.allowDomain() werd aangeroepen, het benaderde SWF-bestand elk SWF-bestand zijn in hetzelfde domein als het bestand dat Security.allowDomain() had aangeroepen. Voorheen werd bij het aanroepen van Security.allowDomain() het gehele domein van het aanroepende SWF-bestand toegankelijk gemaakt.
• Jokertekenwaarden worden nu ondersteund met Security.allowDomain('*') en Security.allowInsecureDomain('*'). Het jokerteken (*) maakt cross-scriptingbewerkingen mogelijk, waarbij het benaderende bestand elk willekeurig bestand is dat vanaf elke willekeurige locatie kan worden geladen. Beschouw het jokerteken als een algemene bevoegdheid. Jokertekenbevoegdheden zijn vereist om bepaalde bewerkingen te kunnen uitvoeren onder de beveiligingsregels voor lokale bestanden. Een lokaal SWF-bestand met netwerktoegangsbevoegdheden kan alleen scriptbewerkingen op een SWF-bestand op internet uitvoeren wanneer dat bestand Security.allowDomain('*') aanroept om aan te geven dat de oorsprong van een lokaal SWF-bestand onbekend is. (Wanneer het SWF-bestand op internet wordt geladen vanaf een HTTPS-URL, moet het SWF-bestand op internet in plaats daarvan Security.allowInsecureDomain('*') aanroepen.)

Soms kan de volgende situatie zich voordoen: u laadt een onderliggend SWF-bestand uit een ander domein en wilt dit onderliggende SWF-bestand toestaan scriptbewerkingen op het bovenliggende SWF-bestand uit te voeren, maar u kent het uiteindelijke domein niet van het onderliggende SWF-bestand. Dit kan bijvoorbeeld het geval zijn wanneer u taakverdelende omleidingen of servers van derden gebruikt.

U kunt dan de eigenschap url gebruiken van het object URLRequest dat u doorgeeft aan Loader.load(). Wanneer u bijvoorbeeld een onderliggend SWF-bestand in een bovenliggend SWF-bestand laadt, hebt u toegang tot de eigenschap contentLoaderInfo van het object Loader voor het bovenliggende SWF-bestand:

Security.allowDomain(loader.contentLoaderInfo.url)

Wacht totdat het laden van het onderliggende SWF-bestand begint zodat de juiste waarde uit de eigenschap url wordt opgehaald. U kunt met de gebeurtenis progress bepalen wanneer het laden van het onderliggende SWF-bestand is gestart.

De tegengestelde situatie kan zich ook voordoen: u maakt een onderliggend SWF-bestand dat het bovenliggende bestand toestaat er scriptbewerkingen op uit te voeren, maar u weet niet wat het domein van het bovenliggende bestand zal zijn. U kunt dan de eigenschap loaderInfo van het weergaveobject openen dat het hoofdobject is van het SWF-bestand. Roep in het onderliggende SWF-bestand Security.allowDomain( this.root.loaderInfo.loaderURL) aan. U hoeft dan niet te wachten tot het bovenliggende SWF-bestand is geladen. Het bovenliggende bestand is al geladen tegen de tijd dat het onderliggende bestand wordt geladen.

Wanneer u voor Flash Player 8 en hoger publiceert, kunt u in dergelijke situaties ook Security.allowDomain('*') aanroepen. Dit kan soms echter gevaarlijk zijn, omdat het aanroepende SWF-bestand in dat geval kan worden geopend door andere SWF-bestanden uit andere domeinen. Het is doorgaans veiliger de eigenschap _url te gebruiken.

Lees voor meer informatie over beveiliging het onderwerp Security in het Flash Player Developer Center.

Parameters

Verwante API-elementen

Hiermee krijgen SWF-bestanden en HTML-bestanden in de opgegeven domeinen toegang tot objecten en variabelen in het aanroepende SWF-bestand, dat via het HTTPS-protocol wordt aangeboden.

Flash Player biedt allowInsecureDomain() voor een optimale flexibiliteit, maar het aanroepen van deze methode wordt niet aanbevolen. Wanneer een bestand via HTTPS beschikbaar wordt gesteld, worden u en uw gebruikers op verschillende manieren beschermd. Wanneer allowInsecureDomain wordt aangeroepen, gaat dit ten koste van deze beveiliging.

Opmerking: Als deze methode wordt aangeroepen vanuit code in de beveiligingssandbox van de AIR-toepassing, wordt er een SecurityError-uitzondering gegenereerd. Inhoud van buiten het beveiligingsdomein van de toepassing kan niet rechtstreeks cross-scripting uitvoeren op inhoud binnen de beveiligingssandbox. Inhoud buiten de sandbox van de toepassing kan echter met behulp van een sandboxbridge wel communiceren met inhoud binnen de beveiligingssandbox van de toepassing.

Deze methode werkt op dezelfde wijze als Security.allowDomain(), maar staat ook bewerkingen toe waarbij de benaderende partij met een niet-HTTPS-protocol wordt geladen en de benaderde partij met HTTPS. In Flash Player 7 en hoger kunnen niet-HTTPS-bestanden geen scriptbewerkingen uitvoeren op HTTPS-bestanden. Wanneer het benaderde HTTPS SWF-bestand de methode allowInsecureDomain() gebruikt, geldt deze beperking niet.

Gebruik allowInsecureDomain() alleen om scriptbewerkingen van niet-HTTPS-bestanden op HTTPS-bestanden toe te staan. Gebruik deze methode om scriptbewerkingen toe te staan wanneer het benaderende niet-HTTPS-bestand en het benaderde HTTPS-bestand zich in hetzelfde domein bevinden, bijvoorbeeld wanneer een SWF-bestand op http://mysite.com scriptbewerkingen wil uitvoeren op een SWF-bestand op https://mysite.com. Gebruik deze methode niet om scriptbewerkingen tussen niet-HTTPS-bestanden, tussen HTTPS-bestanden of van HTTPS-bestanden op niet-HTTPS-bestanden toe te staan. Gebruik in die gevallen allowDomain().

De volgende informatie is slechts één mogelijk scenario, bedoeld om u te helpen allowInsecureDomain() te begrijpen door middel van een praktisch voorbeeld van cross-scripting. In dit voorbeeld komen niet alle aspecten van beveiligingsarchitectuur aan bod en dit voorbeeld moet dan ook uitsluitend als achtergrondinformatie worden beschouwd. Het Flash Player Developer Center bevat uitgebreide informatie over Flash Player en beveiliging. Lees voor meer informatie het onderwerp Security in het Flash Player Developer Center.

Stel dat u een e-commercesite bouwt die uit twee componenten bestaat: een catalogus, die niet hoeft te worden beveiligd omdat deze alleen openbare gegevens bevat, en een winkelwagen-/kassacomponent, die wel moet worden beveiligd om de financiële en persoonlijke gegevens van gebruikers te beschermen. Stel dat u overweegt de catalogus weer te geven op http://mysite.com/catalog.swf en de winkelwagen op https://mysite.com/cart.swf. Eén vereiste voor uw site is dat een derde partij de creditcardnummers van uw gebruikers niet kan stelen door gebruik te maken van een zwakke plek in uw beveiligingsarchitectuur.

Stel dat een derde partij inbreekt op een positie tussen uw server en uw gebruikers en de creditcardnummers probeert te stelen die uw gebruikers in uw winkelwagentoepassing invoeren. Deze partij kan een gewetenloze internetprovider zijn die door sommigen van uw gebruikers wordt gebruikt, een kwaadwillende beheerder die een collega is van een van de gebruikers of ieder ander die netwerkpakketten kan weergeven of wijzigen die tussen uw gebruikers en uw servers via het publieke internet worden verzonden. Dit komt vaker voor dan u denkt.

Wanneer cart.swf HTTPS gebruikt voor de verzending van creditcardgegevens naar uw servers, kan de kwaadwillende partij deze gegevens niet rechtstreeks uit netwerkpakketten stelen, omdat de HTTPS-verzending gecodeerd is. De kwaadwillende partij kan echter wel een andere techniek gebruiken: deze kan de inhoud van een van uw SWF-bestanden wijzigen wanneer deze aan de gebruiker wordt geleverd, door uw SWF-bestand te vervangen door een gewijzigde versie die de gegevens van de gebruiker naar een andere server verzendt, een server van de kwaadwillende partij.

Met het HTTPS-protocol wordt onder andere voorkomen dat deze wijzigingsaanval werkt, doordat HTTPS-verzendingen worden gecodeerd en er niet mee kan worden geknoeid. Wanneer een tussenpartij een pakket wijzigt, detecteert de ontvangende kant de wijzigingen en wordt het pakket genegeerd. In deze situatie kan de aanvaller cart.swf dus niet wijzigen, omdat het bestand via HTTPS wordt geleverd.

Stel echter dat u in catalog.swf, dat via HTTP beschikbaar wordt gesteld, knoppen wilt opnemen waarmee items aan het winkelwagentje in cart.swf kunnen worden toegevoegd dat via HTTPS beschikbaar wordt gesteld. Hiertoe roept cart.swf allowInsecureDomain() aan om catalog.swf in staat te stellen scriptbewerkingen uit te voeren op cart.swf. Deze handeling heeft een onbedoeld gevolg: de aanvaller kan catalog.swf nu wijzigen wanneer het bestand door de gebruiker wordt gedownload, omdat catalog.swf via HTTP wordt geleverd en het bestand kwetsbaar is voor wijzigingen. Het door de aanvaller gewijzigde bestand catalog.swf kan nu scriptbewerkingen op cart.swf uitvoeren omdat cart.swf een aanroep van allowInsecureDomain() bevat. Het gewijzigde bestand catalog.swf kan ActionScript-code gebruiken om toegang te krijgen tot de variabelen in cart.swf en zo de creditcardgegevens en andere gevoelige gegevens van de gebruiker lezen. Het gewijzigde bestand catalog.swf kan deze gegevens naar de server van een aanvaller verzenden.

Vanzelfsprekend is deze implementatie niet gewenst, maar u wilt cross-scripting tussen de twee SWF-bestanden op uw site wel toestaan. U kunt deze hypothetische e-commercesite op twee manieren opnieuw ontwerpen om allowInsecureDomain() te voorkomen:

• Geef alle SWF-bestanden in de toepassing weer via HTTPS. Dit is verreweg de meest eenvoudige en betrouwbare oplossing. In het beschreven scenario zou u zowel catalog.swf als cart.swf via HTTPS weergeven. Er kan iets meer bandbreedte worden verbruikt, de CPU-belasting van de server kan iets hoger zijn en toepassingen worden mogelijk iets trager geladen bij overschakeling van een bestand als catalog.swf van HTTP naar HTTPS. Experimenteer met echte servers om de ernst van deze effecten te bepalen. Doorgaans verslechtert de situatie met maximaal 10-20%, maar soms treden deze effecten helemaal niet op. U kunt resultaten doorgaans verbeteren met HTTPS-versnellende hardware of -software op uw servers. Het beschikbaar stellen van alle samenwerkende SWF-bestanden via HTTPS biedt als groot voordeel dat u een HTTPS-URL als hoofd-URL in de browser van de gebruiker kunt gebruiken zonder dat waarschuwingen over gemengde inhoud door de browser worden gegenereerd. Daarnaast wordt het hangslotpictogram van de browser weergegeven om uw gebruikers een bekende en vertrouwde indicator van veiligheid te bieden.
• Gebruik HTTPS-naar-HTTP-scripting in plaats van HTTP-naar-HTTPS-scripting. In het beschreven scenario kunt u de inhoud van het winkelwagentje van de gebruiker opslaan in catalog.swf en met cart.swf alleen het afrekenen beheren. Wanneer de bestelling wordt geplaatst en afgerekend, kan cart.swf de inhoud van het winkelwagentje ophalen uit ActionScript-variabelen in catalog.swf. De beperking op HTTP-naar-HTTPS-scripts is asymmetrisch: hoewel het via HTTP geleverde bestand catalog.swf geen scriptbewerkingen mag uitvoeren op het via HTTPS geleverde bestand cart.swf, is dit andersom wel mogelijk. Deze methode is kwetsbaarder dan de methode waarbij alleen van HTTPS wordt gebruikgemaakt. U moet SWF-bestanden die via HTTP worden geleverd nooit vertrouwen, omdat met deze bestanden eenvoudig kan worden geknoeid. Wanneer cart.swf bijvoorbeeld de ActionScript-variabele ophaalt waarmee de inhoud van het winkelwagentje wordt beschreven, kan de ActionScript-code in cart.swf er niet op vertrouwen dat de waarde van deze variabele de verwachte notatie heeft. U moet controleren of het winkelwagentje geen ongeldige gegevens bevat die ertoe kunnen leiden dat cart.swf een ongewenste handeling uitvoert. Daarnaast moet u het risico accepteren dat een tussenpartij catalog.swf kan wijzigen door geldige, maar onjuiste gegevens aan cart.swf toe te voegen, bijvoorbeeld door items in het winkelwagentje van de gebruiker te plaatsen. Tijdens een normale afrekenprocedure wordt dit risico beperkt, omdat de inhoud van het winkelwagentje en de totale kosten ter goedkeuring worden weergegeven, maar er blijft een risico aan verbonden.

In webbrowsers worden HTTPS- en niet-HTTPS-bestanden al jaren gescheiden gehouden en het beschreven scenario illustreert één goede reden voor deze beperking. Flash Player biedt u de mogelijkheid deze beveiligingsbeperking te omzeilen wanneer dit echt nodig is, maar weeg de consequenties zorgvuldig af voordat u dit doet.

Lees voor meer informatie over beveiliging het onderwerp Security in het Flash Player Developer Center.

Parameters

Verwante API-elementen

Er wordt gezocht naar een beleidsbestand op de locatie die is opgegeven met de parameter url. Adobe AIR en Flash Player gebruiken beleidsbestanden om te bepalen of toepassingen gegevens mogen laden van andere servers dan de eigen server. Hoewel de methode de naam loadPolicyFile() heeft, wordt het bestand pas geladen op het moment dat er een netwerkaanvraag wordt verzonden waarvoor een beleidsbestand vereist is.

Met Security.loadPolicyFile() kan Flash Player of AIR beleidsbestanden laden vanaf alle willekeurige locaties, zoals in het volgende voorbeeld wordt getoond:

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

Hiermee haalt Flash Player of AIR een beleidsbestand op van de opgegeven URL. Eventuele machtigingen die door het beleidsbestand op die locatie zijn verleend, worden toegepast op alle inhoud op hetzelfde niveau of lager in de virtuele maphiërarchie van de server.

Zo wordt op basis van de voorgaande code door deze regels geen uitzondering gegenereerd:

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

In de volgende code wordt echter wel een uitzondering gegenereerd:

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

U kunt loadPolicyFile() gebruiken om het gewenste aantal beleidsbestanden te laden. Wanneer Flash Player of AIR een aanvraag om een beleidsbestand beoordeelt, wordt altijd gewacht tot de beleidsbestanden zijn gedownload voordat een aanvraag wordt afgewezen. Als laatste mogelijkheid, wanneer geen beleidsbestand dat met loadPolicyFile() is opgegeven een aanvraag goedkeurt, raadpleegt Flash Player of AIR de oorspronkelijke standaardlocaties.

Wanneer Flash Player controleert of er een hoofdbeleidsbestand aanwezig is, wacht het drie seconden op een reactie van de server. Als er geen reactie wordt ontvangen, gaat Flash Player ervan uit dat er geen hoofdbeleidsbestand bestaat. Er is echter geen standaardtime-outwaarde voor aanroepen naar loadPolicyFile(). Flash Player gaat ervan uit dat het aangeroepen bestand bestaat en wacht zo lang als nodig is om het te laden. Als u er dus voor wilt zorgen dat er een hoofdbeleidsbestand wordt geladen, moet u loadPolicyFile() gebruiken om het expliciet aan te roepen.

U kunt geen verbinding maken met algemeen gereserveerde poorten. Zie "Netwerk-API's beperken" in de Adobe ActionScript 3.0-ontwikkelaarsgids voor een volledige lijst van geblokkeerde poorten.

Wanneer u het protocol xmlsocket samen met een specifiek poortnummer gebruikt, kunt u beleidsbestanden rechtstreeks vanaf een XMLSocket-server ophalen, zoals in het volgende voorbeeld wordt geïllustreerd. Voor socketverbindingen gelden de beperkingen omtrent gereserveerde poorten zoals hierboven beschreven niet.

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

Hiermee probeert Flash Player of AIR een beleidsbestand op te halen van de opgegeven host en poort. Nadat een verbinding met de opgegeven poort tot stand is gebracht, verzendt Flash Player of AIR <policy-file-request />, dat met een null-byte wordt afgesloten. De server moet een null-byte verzenden om een beleidsbestand te beëindigen en kan vervolgens de verbinding sluiten. Wanneer de server de verbinding niet sluit, doet Flash Player of AIR dat nadat de afsluitende null-byte wordt ontvangen.

U kunt voorkomen dat een SWF-bestand deze methode gebruikt door de parameter allowNetworking in te stellen van de tags object en embed op de HTML-pagina die de SWF-inhoud bevat.

Lees voor meer informatie over beveiliging het onderwerp Security in het Flash Player Developer Center.

Parameters

Geeft het deelvenster met beveiligingsinstellingen in Flash Player weer. Deze methode is niet van toepassing op inhoud in Adobe AIR; wanneer deze in een AIR-toepassing wordt aangeroepen, heeft dit geen effect.

Parameters

Verwante API-elementen

Het bestand wordt in een AIR-toepassing uitgevoerd en is geïnstalleerd met het pakket (het AIR-bestand) voor die toepassing. Deze content bevindt zich in de bronmap van de AIR-toepassing (waar de inhoud van de toepassing is geïnstalleerd).

Verwante API-elementen

Het bestand is een lokaal bestand dat door de gebruiker als vertrouwd is opgegeven via Settings Manager van Flash Player of een configuratiebestand in de map FlashPlayerTrust. Het bestand kan informatie lezen van lokale gegevensbronnen en kan met internet communiceren.

Verwante API-elementen

Het bestand is een lokaal bestand dat niet door de gebruiker als vertrouwd is opgegeven en is niet een SWF-bestand dat met een netwerkbestemming is gepubliceerd. In Adobe AIR bevindt het lokale bestand zich niet in de bronmap van de toepassing; dergelijke bestanden worden in de beveiligingssandbox van de toepassing geplaatst. Het bestand kan informatie van lokale gegevensbronnen lezen, maar kan niet met internet communiceren.

Verwante API-elementen

Het bestand is een lokaal bestand dat niet door de gebruiker als vertrouwd is opgegeven en is een SWF-bestand dat met een netwerkbestemming is gepubliceerd. Het bestand kan met internet communiceren maar kan geen informatie lezen van lokale gegevensbronnen.

Verwante API-elementen

Het bestand is afkomstig van een internet-URL en wordt uitgevoerd volgens op domein gebaseerde sandboxregels.

Verwante API-elementen