KorsskriptningFlash Player 9 och senare, Adobe AIR 1.0 och senare Om två SWF-filer som är skrivna med ActionScript 3.0, eller två HTML-filer som körs i AIR opereras från samma domän, där URL:en för den ena SWF-filen till exempel är http://www.example.com/swfA.swf och för den andra http://www.example.com/swfB.swf, kan kod som definieras i den ena filen undersöka och ändra variabler, objekt, egenskaper, metoder o.s.v. i den andra och vice versa. Detta kallas korsskriptning. De två filerna kan också opereras från olika domäner, till exempel http://siteA.com/swfA.swf och http://siteB.com/swfB.swf. I sådana fall är standard att Flash Player och AIR inte tillåter att swfA.swf skriptar swfB.swf, eller att swfB.swf skriptar swfA.swf. En SWF-fil ger SWF-filer från andra domäner behörighet genom att anropa Security.allowDomain(). Genom att anropa Security.allowDomain("siteA.com") ger siteB.swf SWF-filer från siteA.swf behörighet att skripta den. Korsskriptning används inte mellan AVM1 SWF- och AVM2 SWF-filer. En AVM1 SWF-fil har skapats med ActionScript 1.0 eller ActionScript 2.0. (AVM1 och AVM2 betyder ActionScript Virtual Machine.) Däremot kan du använda klassen LocalConnection för att skicka data mellan AVM1 och AVM2. I alla korsdomänssituationer är det viktigt att veta vilken sida som är vilken. I beskrivningarna kommer sidan som utför korsskriptningen att kallas den anslutande parten (vanligtvis den anslutande SWF-filen) och den andra sidan kallas målparten (vanligtvis SWF-målfilen). När siteA.swf skriptar siteB.swf är siteA.swf den anslutande parten och siteB.swf målparten, som illustreras här: Korsdomänbehörigheter som upprättas med metoden Security.allowDomain() är asymmetriska. I föregående exempel kan siteA.swf skripta siteB.swf, men siteB.swf kan inte skripta siteA.swf eftersom siteA.swf inte har anropat metoden Security.allowDomain() för att ge SWF-filer på siteB.com behörighet att skripta den. Du kan ange symmetrisk behörighet genom att låta båda SWF-filerna anropa metoden Security.allowDomain(). Flash Player skyddar SWF-filer från korsdomänsskriptning från andra SWF-filer och från korsdomänsskriptning från HTML-filer. HTML-till-SWF-skriptning kan utföras med återkopplingar (callback) som upprättats via metoden ExternalInterface.addCallback(). När skriptning från HTML till SWF går över domäner, måste SWF-målfilen anropa metoden Security.allowDomain(), precis som när den anslutande parten är en SWF-fil, annars misslyckas åtgärden. Mer information finns i Författarinställningar (för utvecklare). I Flash Player finns dessutom säkerhetskontroller för SWF-till-HTML-skriptning. Mer information finns i Kontrollera utgående URL-åtkomst. scen, säkerhetVissa egenskaper och metoder i objektet Stage kan användas med Sprite- eller MovieClip-objekt i visningslistan. Objektet Stage har däremot en ägare: den först inlästa SWF-filen. Följande egenskaper och metoder i objektet Stage är som standard endast tillgängliga för SWF-filer i samma säkerhetssandlåda, som är objektsägare:
För att en SWF-fil i en annan sandlåda än gällande objektsägares sandlåda ska få tillgång till dessa egenskaper och metoder, måste scenägarens SWF-fil anropa metoden Security.allowDomain() och ge behörighet till domänen för den externa sandlådan. Mer information finns i Författarinställningar (för utvecklare). Egenskapen frameRate är ett undantag – samtliga SWF-filer kan läsa egenskapen frameRate. Däremot kan endast de filer som finns i objektsägarens säkerhetssandlåda (eller de som har behörighet via anrop av metoden Security.allowDomain()) ändra egenskapen. Det finns även begränsningar för metoderna removeChildAt() och swapChildrenAt() i Stage-objektet, men de skiljer sig från andra begränsningar. För att anropa dessa metoder måste koden finnas i samma domän som ägaren av berörda underordnade objekt, alternativt kan underordnade objekt anropa metoden Security.allowDomain(), i stället för att de måste ligga i samma domän som objektsägaren. Gå igenom visningslistanMöjligheten att en SWF-fil har åtkomst till visningsobjekt som är inlästa från andra sandlådor är begränsad. För att en SWF-fil ska få åtkomst till ett visningsobjekt som skapats av en annan SWF-fil i en annan sandlåda, måste SWF-filen anropa metoden Security.allowDomain() för att ge behörighet från domänen. Mer information finns i Författarinställningar (för utvecklare). För att få åtkomst till Bitmap-objektet som lästes in med Loader-objektet måste det finnas en URL-principfil på bildfilens ursprungliga server. Denna korsdomänprincip måste ge behörighet till domänen med SWF-filen som försöker få åtkomst till Bitmap-objektet (seWebbplatsinställningar (principfiler)). Objektet LoaderInfo som har en motsvarande inläst fil (och ett Loader-objekt) innehåller följande tre egenskaper som definierar relationen mellan det inlästa objektet och Loader-objektet: childAllowsParent, parentAllowsChild och sameDomain. Säkerhet med händelserHändelser som berör visningslistan har begränsningar för åtkomst, baserat på sandlådan varifrån visningsobjektet skickar händelsen. En händelse i visningslistan har bubblings- och hämtningsfaser (beskrivs i Hantera händelser). Under bubblings- och hämtningsfaserna flyttas en händelse från källvisningsobjektet via överordnade visningsobjekt i visningslistan. Om ett överordnat objekt ligger i en annan säkerhetssandlåda än källvisningsobjektet stannar bubblings- och hämtningsfasen nedanför det överordnade objektet, såvida det inte finns inbördes tillförlitlighet hos både ägaren av överordnat objekt och ägaren av källobjekt. En sådan inbördes tillförlitlighet skapas genom följande:
Objektet LoaderInfo som har en motsvarande inläst fil (och ett Loader-objekt) innehåller följande två egenskaper som definierar relationen mellan det inlästa objektet och Loader-objektet: childAllowsParent och parentAllowsChild. För händelser som skickas från andra objekt än visningsobjekt finns det inga säkerhetskontroller eller säkerhetsrelaterade konsekvenser. |
|