[AS] URLLoader 외부 URL load 보안 관련 Security Domains, Application Domains, and More in ActionScript 3.0

ADOBE/ ActionScript

by AlrepondTech 2020. 9. 22. 02:33

=================================

[Flex/AIR]BitmapData를 PNG나 JPG로 변환하여 ByteArray로 서버에 전송하는 방법<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

로컬자원을 서버에 전송하기 위해 우리는 FileReference Class를 사용하면 된다.
FileReference로FileReference로 파일을 서버에 전송하는 방법은 많이 공개가 되어 있다.
알다시피 FileReference의 browse()함수를browse()함수를 호출한 뒤, select 이벤트가 발생시 upload() 함수를 이용하여 선택한 로컬자원을 서버로서버로 보낸다.

서버에서는 아주 단순하게 서버 임시 저장소에 저장된 파일을파일을 원하는 곳에 복사하기만 하면 된다.
php의 경우 move_uploaded_file() 메소드를 사용하면사용하면 되겠다.

그럼 Flex 시행도중 캡쳐한 화면을 저장하는 경우에도 위와 같은같은 방법으로 저장이 가능할까?

답은 "된다"

나는 예전에 ImageSnapshotImageSnapshot 클래스를 이용해 base64로 변환해서 서버로 전송한 뒤에 base64를 decode하여 저장하는 방법에방법에 대해서 언급한적이 있다. (http://blog.jidolstar.com/301 참고)
이 방법의 단점은 이미지가 큰 경우경우 base64로 encode, decode 하는 과정에서 서버성능 및 클라이언트 성능에 따라 속도속도 및 부하에 영향을 준다. 그러므로 이 방법으로는 PNGEncoder 및 JPGEncoder로 PNG,PNG, JPG 파일 형식에 맞는 데이타를 만들었다고 해도, FileReference와 같이 데이타를 전송을전송을 할 수 없었다.

하지만 Google을 열심히 돌아다녔다니 이 문제점에 대한대한 해결의 실마리를 찾을 수 있었다.
(역시 Google!!!)

간단히 방법을 요약하자면요약하자면
화면을 BitmapData로 만들어 PNGEncoder나 JPGEncoder를 이용하여 encode한 다음, 그 결과값인결과값인 byteArray값을 서버에 전송한다. 전송된 데이타는 FileReference에서 upload()을 이용해 보낸 파일을 저장할때와저장할때와 동일하게 저장하면 되겠다.

1.1. BitmapData로 캡쳐해라.

아래 target은 캡쳐할 UIComponent와UIComponent와 같은 DisplayObject 객체이다.

BitmapData로 캡쳐

var bitmapData:BitmapData = new BitmapData(target.width, target.height, true, 0xFFFFFF);
var drawingRectangle:Rectangle = new Rectangle(0, 0, target.width, target.height);
bitmapData.draw(target, new Matrix(), null, null, drawingRectangle, false);

단, BitmapData를 이용해서 화면을 캡쳐할 대상이 외부 동영상이나 사진같은사진같은 거라면 crossdomain.xml 에 대한 check가 있어야한다. 컨텐츠 로드시 checkPolicyFile 속성을 속성을 true로 설정할 필요가 있겠다.
그리고 2880px 이상의 크기는 BitmapData로 만들 수수 없다.

2.2. JPG나 PNG로 Encode 하여 ByteArray를 얻는다.

Flex 3 SDK에는 mx.graphics.codec 패키지에 JPGEncoder와 PNGEncoder가 있다. 인터넷을 뒤져보면뒤져보면 GIFEncoder등도 있을것이다. Flex 2 환경에서 작업한다면 Google code에 Adobe AS3 Corelib에Corelib에 이들이 제공된다. 만약 JPGEncoder를 사용한다면 다음과 같이 하면 되겠다.

JPGEncoder를 이용하여 JPG ByteArray값 만들기

import mx.graphics.codec.JPGEncoder;

var byteArray:ByteArray = new JPGEncoder().encode(bitmapData);

Flex 3 SDK는 이러한 Encoder가 IImageEncoder로 구현되었다. 필요하다면 언제언제 어디서나 Encoder를 바꿔야 하는 경우IImageEncoder를 사용하는 것이 좋을 수 있겠다.있겠다.
가령 아래 예제처럼 말이다.

다양한 Image Encoder 사용하기사용하기

import mx.graphics.codec.*;

var imageType:String = "jpg";
var imageEncoder:IImageEncoder;
if( imageType.toUpperCase() == "JPG" ) imageEncoder= new JPEGEncoder();
else if( imageType.toUpperCase() == "PNG" ) imageEncoder= new PNGEncoder();
var byteArray:ByteArray = imageEncoder.encode(bitmapData);

3. 서버에 ByteArray를 전송한다.

데이타를 전송할때는 FileReference를 사용하지 않는다.
바로 URLLoader와 URLRequest만 이용해서이용해서 전송이 가능하다. 참고 데이타는 POST방식으로 URLVariable을 이용해서 보낼 수있다.

Flex/AIR 데이터 전송 방법

//assumed variable declarations
//var byteArray:ByteArray = 2번째 단계에서 JPG 데이타를 얻었다.
//var fileName:String = "desiredfilename.jpg" //저장할 파일 이름이다. 아무거나 적자!
//var uploadPath:String = "저장할 때 사용되는 서버측 script 경로"
//var parameters:URLVariables = 이미지 이외에 다른 보낼 다른 데이타가 있다면 이것을 이용한다.
//function onComplete(eventObj:Event):void { 성공적으로 데이타를 전송했을때 핸들러 함수 정의
//function onError(eventObj:ErrorEvent):void { 이미지 전송을 실패했을때 핸들러 함수 정의

var urlRequest:URLRequest = new URLRequest();
urlRequest.url = uploadPath;
urlRequest.contentType = 'multipart/form-data; boundary=' + UploadPostHelper.getBoundary();
urlRequest.method = URLRequestMethod.POST;
urlRequest.data = UploadPostHelper.getPostData(file, byteArray, parameters);
urlRequest.requestHeaders.push( new URLRequestHeader( 'Cache-Control', 'no-cache' ) );

var urlLoader:URLLoader = new URLLoader();
urlLoader.dataFormat = URLLoaderDataFormat.BINARY;
urlLoader.addEventListener(Event.COMPLETE, onComplete);
urlLoader.addEventListener(IOErrorEvent.IO_ERROR, onError);
urlLoader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onError);
urlLoader.load(urlRequest);

위에 진한 부분에 대한 클래스는 아래에 정의되어 있다. 당신은당신은 이 클래스가 어떻게 구성되었는가 열심히 공부할 필요가 없다.(원한다면 해도 된다. 말리지말리지 않음 ^^)

UploadPostHelper Class (Language :: java)

package {

  import flash.events.*;
  import flash.net.*;
  import flash.utils.ByteArray;
  import flash.utils.Endian;

  /**
   * Take a fileName, byteArray, and parameters object as input and return ByteArray post data suitable for a UrlRequest as output
   *
   * @see http://marstonstudio.com/?p=36
   * @see http://www.w3.org/TR/html4/interact/forms.html
   * @see http://www.jooce.com/blog/?p=143
   * @see http://www.jooce.com/blog/wp%2Dcontent/uploads/2007/06/uploadFile.txt
   * @see http://blog.je2050.de/2006/05/01/save-bytearray-to-file-with-php/
   *
   * @author Jonathan Marston
   * @version 2007.08.19
   *
   * This work is licensed under a Creative Commons Attribution NonCommercial ShareAlike 3.0 License.
   * @see http://creativecommons.org/licenses/by-nc-sa/3.0/
   *
   */
  public class UploadPostHelper {

  /**
   * Boundary used to break up different parts of the http POST body
   */
  private static var _boundary:String = "";

  /**
   * Get the boundary for the post.
   * Must be passed as part of the contentType of the UrlRequest
   */
  public static function getBoundary():String {

  if(_boundary.length == 0) {
  for (var i:int = 0; i < 0x20; i++ ) {
_boundary += String.fromCharCode( int( 97 + Math.random() * 25 ) );
  }
  }

  return _boundary;
  }

  /**
   * Create post data to send in a UrlRequest
   */
  public static function getPostData(fileName:String, byteArray:ByteArray, parameters:Object = null):ByteArray {

var i: int;
var bytes:String;

var postData:ByteArray = new ByteArray();
postData.endian = Endian.BIG_ENDIAN;

  //add Filename to parameters
  if(parameters == null) {
parameters = new Object();
  }
parameters.Filename = fileName;

  //add parameters to postData
  for(var name:String in parameters) {
postData = BOUNDARY(postData);
postData = LINEBREAK(postData);
bytes = 'Content-Disposition: form-data; name="' + name + '"';
  for ( i = 0; i < bytes.length; i++ ) {
postData.writeByte( bytes.charCodeAt(i) );
  }
postData = LINEBREAK(postData);
postData = LINEBREAK(postData);
postData.writeUTFBytes(parameters[name]);
postData = LINEBREAK(postData);
  }

  //add Filedata to postData
postData = BOUNDARY(postData);
postData = LINEBREAK(postData);
bytes = 'Content-Disposition: form-data; name="Filedata"; filename="';
  for ( i = 0; i < bytes.length; i++ ) {
postData.writeByte( bytes.charCodeAt(i) );
  }
postData.writeUTFBytes(fileName);
postData = QUOTATIONMARK(postData);
postData = LINEBREAK(postData);
bytes = 'Content-Type: application/octet-stream';
  for ( i = 0; i < bytes.length; i++ ) {
postData.writeByte( bytes.charCodeAt(i) );
  }
postData = LINEBREAK(postData);
postData = LINEBREAK(postData);
postData.writeBytes(byteArray, 0, byteArray.length);
postData = LINEBREAK(postData);

  //add upload filed to postData
postData = LINEBREAK(postData);
postData = BOUNDARY(postData);
postData = LINEBREAK(postData);
bytes = 'Content-Disposition: form-data; name="Upload"';
  for ( i = 0; i < bytes.length; i++ ) {
postData.writeByte( bytes.charCodeAt(i) );
  }
postData = LINEBREAK(postData);
postData = LINEBREAK(postData);
bytes = 'Submit Query';
  for ( i = 0; i < bytes.length; i++ ) {
postData.writeByte( bytes.charCodeAt(i) );
  }
postData = LINEBREAK(postData);

  //closing boundary
postData = BOUNDARY(postData);
postData = DOUBLEDASH(postData);

  return postData;
  }

  /**
   * Add a boundary to the PostData with leading doubledash
   */
  private static function BOUNDARY(p:ByteArray):ByteArray {
var l:int = UploadPostHelper.getBoundary().length;

p = DOUBLEDASH(p);
  for (var i:int = 0; i < l; i++ ) {
p.writeByte( _boundary.charCodeAt( i ) );
  }
  return p;
  }

  /**
   * Add one linebreak
   */
  private static function LINEBREAK(p:ByteArray):ByteArray {
p.writeShort(0x0d0a);
  return p;
  }

  /**
   * Add quotation mark
   */
  private static function QUOTATIONMARK(p:ByteArray):ByteArray {
p.writeByte(0x22);
  return p;
  }

  /**
   * Add Double Dash
   */
  private static function DOUBLEDASH(p:ByteArray):ByteArray {
p.writeShort(0x2d2d);
  return p;
  }

  }
}

한가지한가지 중요한 정보를 언급하겠다.
URLLoader를 이용해 서버에 전송할때, 프로그램이 같은같은 도메인상에 있는 경우에는 보안문제가 없다. 하지만 다른 도메인에 위치한 서버로 이미지를이미지를 전송할때는 반드시 crossdomain.xml을 check해야한다.

1. Security.loadPolicyFile(http://다른도메인/crossdomain.xml); 를 URLLoader의URLLoader의 load()함수를 호출하기 전에 호출한다.

2. Flash Player 9.0.124.0 버전부터는버전부터는 HTTP Header 보안취약점을 해결하기 위해서 cross domain 정책이 변경되었는데.... 서버측에 있는있는 crossdomain.xml에 allow-http-request-headers-from가 추가되어져야 한다. 이것은 HTTP 헤더 전송을 허용할지 결정해준다.

crossdomain.xml (Language : xml)

<?xml version="1.0"?>
http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.jidolstar.com" />
<allow-http-request-headers-from domain="*.jidolstar.com" headers="*"/>
</cross-domain-policy>

위 처럼 서버측 crossdomain.xml에 allow-http-request-headers-from을 추가함으로 다른 도메인간에 HTTPHTTP 헤더 전송을 허용할 수있다.

서로 다른 도메인에 SWF와SWF와 서버측 코드가 배치되어 있다면 반드시 이 사실을 숙지하길 바란다.

4. 서버측 코드 작성

만약 위 3번 코드에서 var parameters:URLVariables를 아래와 같이같이 작성했다고 하자.

URLVariables 설정 (Language :: java)

var parameters:URLVariables = new URLVariables();
parameters.method = "id";
parameters.userId = "2000321";

그럼 PHP 코드로 아래와아래와 같은 방법처럼 만들면 되겠다.(테스트는 안해봤음)

PHP 코드 예제예제 (Language : php)

<?php
$method = $_POST['method'];
$userId = $_POST['userId'];
$file_temp = $_FILES['Filedata']['tmp_name'];
$file_name = $_FILES['Filedata']['name'];
$file_size = $_FILES['Filedata']['size'];

if( $method == "id" )
{
$movePath = "/home/myPath/images/$userId_$file_name";
}
else
{
$movePath = "/home/myPath/images/time_".time()."_".$file_name;
}

move_uploaded_file($file_temp,$movePath);

echo "save Complete";
?>

마지막 save Comple 메시지를 받기 위해서는 Flex의 Complete 이벤트 발생시 아래와아래와 같은 방법으로 받으면 되겠다. 이것을 알아내는데도 많이 힘들었다. 일종의 팁이다. ^^;^^;

데이타 받기 (Language : java)

var loader:URLLoader = URLLoader(event.target);
var bytedata:ByteArray = loader.data;
var strData:String = bytedata.toString();
trace( strData)

실제 업무에도 잘 이용하고 있다.
이미지이미지 에디터 등을 만들때 아주아주 유용한 자료가 될 것이다.

누가 예제예제 프로그램 만들어서 트랙백 걸어 주시면 고맙겠다.

자료 출처출처
http://marstonstudio.com/2007/08/19/how-to-take-a-snapshot-of-a-flash-movie-and-automatically-upload-the-jpg-to-a-server-in-three-easy-steps/

지돌스타 블로그내 참고자료
- ImageSnapshot 클래스에 대해 : http://blog.jidolstar.com/301
- FileReference의 UploadCompleteData 이벤트이벤트 : http://blog.jidolstar.com/324
- 동영상 캡쳐 방법 : http://blog.jidolstar.com/215

글쓴이 : 지돌스타(http://blog.jidolstar.com/352)

[출처] BitmapData를 PNG나 JPG로 변환하여 ByteArray로 서버에 전송하는 방법 (통합디자인) |작성자 혀니

=================================

출처: http://cafe.naver.com/multism/2312

문서를 정리한 정도라 도움이 되실지 모르겠네요..^^

* 참고
    - http://flexdocs.kr/docs/flex2/docs/00001953.html#217447
    - http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html
    - http://livedocs.adobe.com/flex/3/html/security2_03.html

    - flash_as3_programming.pdf ( Flash Player 보안 )

문서명	위치
Security Topic Center	http://www.adobe.com/devnet/security
Security Bulletins and Advisories	http://www.adobe.com/support/security
Flash Player Security & Privacy	http://www.adobe.com/products/flashplayer/security
Security Resource Center	http://www.adobe.com/resources/security
Flash Player 9 Security white paper	http://www.adobe.com/go/fp9_0_security
"Flash Player Security" in Programming ActionScript 3.0	http://www.adobe.com/go/progAS3_security
"Networking and Communications" in Programming ActionScript 3.0.	http://www.adobe.com/go/AS3_networking_and_communications
Security Changes in Flash Player 8	http://www.adobe.com/devnet/flash/articles/fplayer8_security.html
Security Changes in Flash Player 7	http://www.adobe.com/devnet/flash/articles/fplayer_security.html
Understanding Service Authentication	http://www.adobe.com/devnet/flex/articles/security_framework_print.html
Settings Manager	http://www.adobe.com/support/flashplayer/help/settings/

Flash Player 보안 모델은 내용 로드, 데이터를 액세스나 로드를 구분합니다.
    ■ 내용 로드 - Loader, Sound 및 NetStream과 같은 클래스를 사용하여 내용을 로드할 수 하는경우

    ■ 데이터 액세스 - URLStream, URLLoader, Socket 및 XMLSocket 등의 클래스를 사용하여 데이터를 로드하는경우,
                      비트맵 객체, BitmapData.draw() , Sound.id3 속성 또는 SoundMixer.computeSpectrum() 사용
                      로드된 미디어에서 데이터를 추출할 수 있습니다.

* 내용 로드의 제한
    ■ 기본적으로 사용자의 하드 드라이브와 같이 네트워크 주소가 아닌 위치에서 로드된 로컬
      SWF 파일은 local-with-filesystem 샌드박스로 분류됩니다.
      이러한 파일은 네트워크에서 내용을 로드할 수 없습니다.
      자세한 내용은 719페이지의 “로컬 샌드박스”를 참조하십시오.

    ■ RTMP(Real-Time Messaging Protocol) 서버로 내용에 대한 액세스를 제한할 수 있습니다.
      자세한 내용은 728페이지의 “RTMP 서버를 사용하여 제공된 내용”을 참조하십시오.

* 권한 컨트롤 개요
    Flash Player 클라이언트 런타임 보안 모델은 리소스를 중심으로 설계되어 있다.
    리소스는 SWF 파일, 로컬 데이터 및 인터넷 URL 등의 객체입니다.

    리소스를 소유하거나 사용하는 관계자는 자신이 소유한 리소스에 대해 컨트롤(보안 설정)을
    실행할 수 있습니다.

    각 리소스에는 네 명의 관계자가 있습니다.

    - 보안 컨트롤 계층 구조
        1. Flash Player에서는 권한 계층 구조를 엄격하게 적용합니다.
        2. 하위의 보안설정이 있더라도 상위의 권한 설정에의해 무시됩니다.

관리자 컨트롤 (사용자기관) 설정

▼

사용자 컨트롤 설정

▼

웹사이트 컨트롤 설정

▼

제작자 컨트롤 설정

* 관리자 컨트롤
    컴퓨터에 관리자 권한으로 로그인한 사용자의 경우 모든 사용자에게
    영향을 주는 Flash Player 보안 설정을 적용할 수 있습니다.

    * 관리자 컨트롤 유형
        ■ mms.cfg 파일
        ■ Global Flash Player Trust 디렉토리

    ■ mms.cfg 파일
        - mms.cfg 파일 경로

운영체체	경로
Macintosh OS X	/Library/Application Support/Macromedia
Windows XP/Vista	C:\WINDOWS\system32\Macromed\Flash
Windows 2000	C:\WINNT\System32\Macromed\Flash
Windows 95/98/ME	C:\WINDOWS\System\Macromed\Flash
Linux	/etc/adobe

         * C:\windows\system32\macromed\flash\mms.cfg
            ■ 데이터 로드    - 로컬 SWF 파일의 읽기를 제한하고 파일 다운로드 및 업로드를 비활성화하며
                               영구 공유 객체에 대한 저장 제한을 설정합니다.
            ■ 개인 정보 제어 - 마이크 및 카메라 액세스를 비활성화하고, SWF 파일에서 윈도우 없는내용을 실행하지 않도록 하며,
                               브라우저 윈도우에 표시된 URL과 일치하지 않는 도메인의 SWF 파일에서
                               영구 공유 객체에 액세스하지 못하도록 합니다.

            ■ Flash Player 업데이트 - Flash Player의 업데이트 버전을 확인하는 간격을 설정하고,
                                      Flash Player 업데이트 정보를 확인하고 해당 업데이트 버전을 다운로드할 URL을 지정하며,
                                      Flash Player 전체에 대한 자동 업데이트를 비활성화합니다.

            ■ 이전 파일 지원        - local-trusted 샌드박스에 이전 버전의 SWF 파일을 배치할지 여부를 지정합니다.
            ■ 로컬 파일 보안        - 로컬 파일을 local-trusted 샌드박스에 배치할 수 있는지 여부를 지정합니다.
            ■ 전체 화면 모드        - 전체 화면 모드를 비활성화합니다.

            SWF 파일은 Capabilities.avHardwareDisable 및 Capabilities.localFileReadDisable 속성을 호출하여
            비활성화된 기능에 대한 일부 정보를 액세스할 수 있습니다.

            그러나 mms.cfg 파일의 설정 대부분은 ActionScript에서 쿼리할 수 없습니다.

            컴퓨터에 응용 프로그램과 무관한 보안 및 개인 정보 보호 정책을 적용하려면 시스템 관리자가
            mms.cfg 파일을 수정해야 합니다.

            응용 프로그램의 설치 관리자에서는 mms.cfg 파일을 사용할 수 없습니다.
            관리자 권한으로 실행되는 설치 관리자는 mms.cfg 파일의 내용을 수정할 수 있지만,
            Adobe는 이러한 사용을 사용자의 신뢰 위반으로 간주하고 설치 프로그램 작성자에게
            mms.cfg 파일을 수정하지 않도록 권고합니다.

    ■ Global Flash Player Trust 디렉토리
        1. Trust 디렉토리 설정을 하면...
            1. 디렉토리내의 SWF 파일은 local-trusted 샌드박스에 할당됩니다.
            2. 다른 SWF 파일과 상호 작용하고 원격이나 로컬의 모든 위치에서 데이터를 로드할 수 있습니다.

        2. 방법

OS	Trus 디렉토리
Windows	C:\windows\system32\Macromed\Flash\FlashPlayerTrust
Mac	/Library/Application Support/Macromedia/FlashPlayerTrust

            1. Trust 디렉토리에 .cfg확장명을 갖도록 파일을 생성한다.
            2. 신뢰하게할 swf파일의 디렉토리를 입력합니다.
                --> 로컬파일 패스, SMB 네트워크 패스를 이용해야합니다.
            예) trust_swf.cfg ( C:\windows\system32\Macromed\Flash\FlashPlayerTrust )

# Trust files in the following directories:C:\Documents and Settings\All Users\Documents\SampleApp

            * 참고
                설치 프로그램을 통해 로컬로 실행되는 SWF 파일을 배포하려는 개발자의 경우,
                설치 프로그램에서 Global Flash Player Trust 디렉토리에 구성 파일을 추가하도록 함으로써,
                배포하는 파일에 전체 권한을 부여할 수 있습니다.

                설치 프로그램은 관리자 권한이 있는 사용자가 실행해야 합니다.
                mms.cfg 파일과 달리 Global Flash Player Trust 디렉토리는 신뢰 권한을 부여하기 위한 목적으로
                설치 프로그램에 포함될 수 있습니다.

* 사용자 컨트롤
    Flash Player에서는 권한 설정에 대해
    설정 UI, 설정 관리자 및 User Flash Player Trust 디렉토리의 서로 다른 세 가지의 사용자 수준 메커니즘을 제공합니다.

    * 보안 관련 옵션 ( 설정 관리자, 설정 UI )
        ■ 카메라 및 마이크 설정 - 사용자가 컴퓨터에서 카메라 및 마이크에 대한 Flash Player 액세스를 제어할 수 있습니다.
                                  사용자가 전체 사이트 또는 특정 사이트에 대한 액세스를 허용하거나 거부할 수 있습니다.
                                  사용자가 전체 사이트나 특정 사이트에 대한 설정을 지정하지 않은 경우,
                                  SWF 파일에서 카메라나 마이크에 액세스하려고 하면,
                                  SWF 파일에서 해당 장치에 액세스하도록 허용할지 여부를 선택할 수 있는 대화 상자가 표시됩니다.
                                  이때, 사용자는 사용할 카메라나 마이크를 지정하고 마이크의 민감도를 설정할 수 있습니다.

        ■ 공유 객체 저장 설정   - 도메인에서 영구 공유 객체 저장에 사용할 디스크 공간을 선택할 수 있습니다.
                                  사용자는 특정 도메인에 대해 임의의 값을 설정하고 새로운 도메인에 대해 기본 설정을 지정할 수 있습니다.
                                  기본 디스크 공간 제한 값은 100KB입니다.
                                  영구 공유 객체에 대한 자세한 내용은 ActionScript 3.0 언어 및 구성 요소 참조 설명서에서
                                  SharedObject 클래스를 참조하십시오.

        ■ 중요 : mms.cfg 파일에 지정된 모든 설정은 설정 관리자에 반영되지 않습니다.

    * User Flash Player Trust 디렉토리
        1. Trust 디렉토리 설정을 하면...
            1. 디렉토리내의 SWF 파일은 local-trusted 샌드박스에 할당됩니다.
            2. 다른 SWF 파일과 상호 작용하고 원격이나 로컬의 모든 위치에서 데이터를 로드할 수 있습니다.

        2. 방법

OS	Trus 디렉토리
Windows	C:\Documents and Settings\USERNAME\Application Data\Macromedia\FlashPlayer\#Security\FlashPlayerTrust
Mac	/Users/JohnD/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust

            1. Trust 디렉토리에 .cfg확장명을 갖도록 파일을 생성한다.
            2. 신뢰하게할 swf파일의 디렉토리를 입력합니다.
                --> 로컬파일 패스, SMB 네트워크 패스를 이용해야합니다.
            예) trust_swf.cfg ( C:\Documents and Settings\USERNAME\Application Data\Macromedia\FlashPlayer\#Security\FlashPlayerTrust )

# Trust files in the following directories:C:\Documents and Settings\All Users\Documents\SampleApp

* 웹 사이트 컨트롤(크로스 도메인 정책 파일:crossdomain.xml)
    1. 크로스 도메인 정책파일 ( crossdomain.xml )을 이용해 웹서버의 데이터를 다른 도메인의 SWF파일에서 사용할 수 있습니다.

    * 액세스에 영향주는 에셋
        ■ 비트맵, 사운드 및 비디오 데이터
        ■ XML 및 텍스트 파일 로드
        ■ 소켓 및 XML 소켓 연결에 대한 액세스
        ■ 다른 보안 도메인의 SWF 파일을 로드하는 SWF 파일의 보안 도메인으로 가져오기
          자세한 사항은 이 장의 뒷부분에 설명되어 있습니다.

    * 정책 파일 구문

http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

       *.example.com, www.friendOfExample.com, 192.0.34.166 시작되는 SWF 파일에
       액세스를 허용하는 정책 파일을 설정합니다.

        domain 속성 : 정확한 IP 주소, 정확한 도메인 또는 와일드카드 도메인(임의의 도메인)을 지정할 수 있습니다.
            * 와일드카드는 IP 도메인 형식에 사용할 수 없습니다.

        secure 속성 : HTTPS가 아닌 서버의 SWF 파일이 HTTPS 서버에서 데이터를 로드할 수 있도록 허용하려면 false로 설정합니다.
                     false로 설정하면 HTTPS에서 제공하는 보안 기능이 약화될 수 있습니다.
                     false로 설정하면 보안 내용이 열려서 스누핑(snooping) 및 스푸핑(spoofing) 공격에 취약해집니다.
                     secure 속성을 false로 설정하지 않아야 합니다.

<allow-access-from domain="www.example.com" secure="false" />

        1. 단계
            1. 메인 SWF에서 타 도메인의 SWF를 접근
            2. Flasy Player가 접근하려는 SWF와 동일 경로의 crossdomain.xml을 로드 시도
                * 다른 경로의 crossdomain.xml을 읽으려면 Security.loadPolicyFile() 메서드를 호출 할 수 있습니다.

            3. 타 도메인 SWF 로드

        2. 정책파일(crossdomain.xml) 적용범위

정책 파일 위치	적용범위
루트 디렉토리	전체 서버
임의의 하위 디렉토리	디렉토리와 하위 디렉토리

    * 소켓 정책 파일

        - XMLSocket 정책 파일 예

<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*" to-ports="507" /><allow-access-from domain="*.example.com" to-ports="507,516" /><allow-access-from domain="*.example2.com" to-ports="516-523" /><allow-access-from domain="www.example2.com" to-ports="507,516-523" /><allow-access-from domain="www.example3.com" to-ports="*" /></cross-domain-policy>

Security.loadPolicyFile("http://socketServerHost.com/crossdomain.xml")

* 정책 파일 미리 로드
    미리 정책파일을 로드하게해야할 경우 아래와 같은 방법을 사용합니다.

    ■ Loader.load() 메서드를 사용하는 경우에는 LoaderContext 객체인
      context 매개 변수의 checkPolicyFile 속성을 설정합니다.

    ■ <img> 태그를 사용하여 텍스트 필드에 이미지를 포함하는 경우,
      <img checkPolicyFile = "true" src = "example.jpg">와 같이 <img> 태그의
      checkPolicyFile 속성을 "true"로 설정합니다.

    ■ Sound.load() 메서드를 사용하는 경우에는 SoundLoaderContext 객체인
      context 매개변수의 checkPolicyFile 속성을 설정합니다.

    ■ NetStream 클래스를 사용하는 경우, NetStream 객체의 checkPolicyFile 속성을 설정합니다.

    * 단계
        1. Flash Player에서 먼저 해당 도메인에서 이미 다운 로드한 모든 정책 파일을 확인합니다.
        2. Security.loadPolicyFile() 메서드에대한 모든 대기 중인 호출을 검토하여
           해당 범위 내에 있는지 확인하고 해당하는 경우 기다립니다.
        3. 서버의 기본 위치에서 크로스 도메인 정책 파일을 찾습니다.

* 제작자(개발자) 컨트롤
    1. 보안 권한을 부여하는 데 사용되는 기본 ActionScript API는 Security.allowDomain() 메서드입니다.
        --> SWF 파일의 접근가능한 도메인 지정합니다.

Security.allowDomain("www.example.com")

        --> www.example.com에서 해당 SWF의 접근을 가능하게 합니다.

    2. Security.allowDomain()의 이용
        1. 192.0.34.166 와 www.example.com 동일한 서버일지라도
           Security.allowDomain("192.0.34.166")로 지정했다면 www.example.com에 액세스 허용 안됨.
        2. Security.allowDomain("*") 모든 도메인에서의 액세스를 허용.

        * 설정가능 권한
            1. SWF 파일 간 크로스 스크립팅
            2. 표시 목록 액세스
            3. 이벤트 감지
            4. Stage 객체의 속성 및 메서드에 대한 전체 액세스

    2. Security.allowInsecureDomain()의 이용
        Security.allowDomain()와 같은 기능을 하며,
        HTTPS(보안프로토콜)내의 SWF, HTTP(비보안 프로토콜)내의 SWF에 모두에서 액세스를 허용하려할때 이용합니다.

        보안 프로토콜과 비보안 프로토콜 간의 스크립팅을 허용한다면 스누핑 및 스푸핑 공격에 취약해집니다.

    3. Security.loadPolicyFile()
        Flash Player는 특정경로의 정책 파일에 접근합니다.

* 보안 샌드박스
    1. 보안샌드박스란?

        샌드박스는 추상적인 개념입니다.
        저는 처음에 샌드박스를 들었을때 무슨 보안옵션창이 실행되는것인가 생각했습니다.

        보안영역을 만드는데 Security 클래스에서 제공하는 여러가지 API 메소드를 이용하거나,
        crossdomain.xml 같은 정책파일을 이용하는 등의 방법으로
        자원에대한 접근 권한을 설정하는 기술입니다.

        클라이언트 컴퓨터는 외부 웹 사이트나 로컬 파일 시스템 등의 여러 소스에서 개별 SWF 파일을 얻습니다.

    2. 원격 샌드박스
        인터넷의 SWF 파일, 여러 자원들을 웹 사이트의 도메인에 해당 하는 별도의 샌드박스에 분류합니다.
        기본적으로 이러한 파일은 해당 서버의 모든 리소스에 대한 액세스가 허용됩니다.

        크로스 도메인 정책을 이용하여 원격 샌드박스를 구성합니다.

    3. 로컬 샌드박스
       로컬 파일은 file: 프로토콜이나 UNC(Universal Naming Convention) 경로를 사용하여
       참조되는 모든 파일을 의미합니다.
       로컬 SWF 파일은 다음 세 로컬 샌드박스 중 하나에 배치됩니다.

        ■ local-with-filesystem 샌드박스
            보안을 위해 Flash Player는 기본적으로 모든 로컬 SWF 파일 및 에셋을
            local-with-file-system 샌드박스에 배치합니다.

            이 샌드박스에서 SWF 파일은 URLLoader 클래스 등을 사용하여
            로컬 파일을 읽을 수 있지만, 네트워크와는 어떤 방식 으로도 통신할 수 없습니다.

            따라서 사용자는 로컬 데이터가 네트워크로 누출되거나 다른 방식으로 부적절하게 공유되지
            않는다는 확신을 가질 수 있습니다.

        ■ local-with-networking 샌드박스
            로컬 파일로 실행되지만 네트워크 액세스가 가능하도록 지정할 수 있습니다.
            local-with-networking 샌드박스에 배치됩니다.

            로컬 파일에 액세스할 수 없습니다.
            네트워크의 데이터에 액세스할 수 있습니다.

            하지만 크로스 도메인 정책 파일이나 Security.allowDomain() 메서드에 대한 호출을
            통해 권한이 부여되지 않는 한 local-with-networking SWF 파일은 여전히 네트워크의
            데이터를 읽을 수 없습니다.

            이러한 권한을 부여하려면 크로스 도메인 정책 파일에서 또는
            Security.allowDomain("*")을 사용하여 모든 도메인에 권한을 부여해야 합니다.

        ■ local-trusted 샌드박스
            사용자나 설치 프로그램에 의해 신뢰할 수 있는 파일로 등록된 로컬 SWF 파일은 local-trusted 샌드박스에 배치됩니다.
            시스템 관리자와 사용자는 보안 고려 사항에 따라 local-trusted 샌드박스에 또는 해당 샌드박스로부터
            로컬 SWF 파일을 재할당하거나 이동할 수도 있습니다
            local-trusted 샌드박스에 할당된 SWF 파일은 다른 SWF 파일과 상호 작용하고 원격이나 로컬의
            모든 위치에서 데이터를 로드할 수 있습니다.

* 로컬 SWF 파일의 샌드박스 유형 설정
    local-with-filesystem 샌드 박스 또는 local-with-networking 샌드 박스용의 SWF 파일은,
    Flex 컴파일러로 use-network 플래그를 설정하는 것에 의해 설정할 수 있습니다.

    상세한 것에 대하여는, 「Flex 어플리케이션의 구축과 deploy」의어플리케이션 컴파일러의 옵션에 대해를 참조해 주세요.

    컴퓨터의 최종 사용자 또는 관리자는, 로컬 SWF 파일을 신뢰할 수 있는 것을 지정해, 로컬 및 네트워크의 다른 도메인으로부터
    데이터를 로드할 수 있도록(듯이) 할 수가 있습니다.

    이것은, Global Flash Player Trust 디렉토리 및 User Flash Player Trust 디렉토리에서 지정합니다.
    상세한 것에 대하여는,관리 유저의 관리 및유저의 관리를 참조해 주세요.

* Security.sandboxType 속성
    - SWF 파일이 사용되고 있는 보안 존의 타입
    - SWF 파일 샌드박스 유형 읽기전용 속성 : Security.sandboxType

    * Security.sandboxType 속성 상수

상수	설명
Security.REMOTE	인터넷 URL에서 가져온 SWF 파일이며 도메인 기반 샌드박스 규칙에 따라 작동합니다.
Security.LOCAL_WITH_FILE	로컬 SWF 파일이지만 사용자가 신뢰하지 않았고 네트워킹이 지정되지 않았습니다. 이 SWF 파일은 로컬 데이터 소스에서 읽을 수 있지만 인터넷과 통신할 수 없습니다.
Security.LOCAL_WITH_NETWORK	로컬 SWF 파일이고 사용자가 신뢰하지 않았지만 네트워킹이 지정되었습니다. 이 SWF 파일은 인터넷과 통신할 수 있지만 로컬 데이터 소스에서 읽을 수는 없습니다.
Security.LOCAL_TRUSTED	로컬 SWF 파일이고 설정 관리자나 Flash Player 신뢰 구성 파일을 사용하여 사용자가 신뢰한 파일입니다. 이 SWF 파일은 로컬 데이터 소스에서 읽을 수 있고 인터넷과 통신할 수 있습니다.

* mxmlc use-network 옵션에 따른 샌드박스 타입의 정의

use-network	SWF 로드 위치	샌드박스 타입
false	로컬	local-with-filesystem
true	로컬	local-with-network
true	네트웍	remote
false	네트웍	n/a (causes an error)

[출처] FLEX 보안 정리 (멀티즘연합-디렉터(Director)) |작성자 낼스

=================================

출처ㅣ http://cafe.naver.com/flashdev/59506

****************************************************************************

*** . 아래와 같은 글의 제목은 삭제 대상 입니다.

*** 예) (1) 제발 알려주세요. 왕초보 입니다.
*** (2) 고수만 보세요.(잘아시는 분만 !)

*** (3) 소스 수정 해 주세요.. 등 등

*** (검색이 어렵거나 질문의 내용과 관계 없는 제목 또는 소스 수정 요청등 광범위한 질문)

***

*** 카페 규칙에 맞지 않는 게시글은 통보 없이 삭제 됩니다.

*** 질문에 대한 상세 규칙 보기 http://cafe.naver.com/flashdev/25835

*

******************************************************************************************

================http://******.hosting.paran.com/crossdomain.xml====================

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-accecss-from domain="*" />
<allow-access-from to-ports="*" />
</cross-domain-policy>

================================================================================

이 정책파일 이구요.

=======소스============

import flash.net.URLRequest;
import flash.net.URLLoader;
import flash.events.Event;

var ip;
Security.loadPolicyFile("http://******.hosting.paran.com/crossdomain.xml");
function ipload()
{
var u:URLRequest = new URLRequest("http://******.hosting.paran.com/ip.php");
u.method = "POST";
var l:URLLoader = new URLLoader();
l.load(u);
l.addEventListener(Event.COMPLETE,com);
function com(e:Event)
{
ipt.text = l.data;
ip = l.data;
}
}
ipload();

=======================

소스는 이렇게됩니다.

이렇게한다음 무비로 내보낸다음에

실행시키면 Adobe Flash Player 보안 창이뜨네요;;

옛날에는 이거 안뜨게 했었는데 기억이 안납니다ㅠㅠ

어떻게 하면 좋을까요?

덧글 0 개

|

등록순

|

인쇄

|

▼답변 1개

등록순

|

최신순

열정멤버

2011.08.18 21:16

l.load(u, new LoaderContext(true));

해보세요

[출처] Adobe Flash Player 보안;;; (플래시(Flash)로 생계를 이어가는 사람들의 모임:플생사모) |작성자 won983212

=================================

출처: http://cafe.naver.com/udone/162

보안을 설정할 수 있는 주체가 아래와 같이 4가지로 구분할 수 있습니다.

설정은 권한 계층에 따라 틀립니다.

1. 관리자 설정 : Administrator (User Institution) settings

2. 사용자 설정 : User settings

3. 웹사이트 설정 : Website settings

4. 개발자 설정 : Author settings

1. 관리자 설정

컴퓨터에 관리자 권한으로 로그인한 관리자의 경우 해당 컴퓨터의 다른 모든 사용자에게

영향을 주는 Flash Player 보안 설정을 적용할 수 있습니다.

가정용 컴퓨터와 같이 엔터프라이즈 환경이 아닌 컴퓨터에는 보통 한 명의 사용자가

관리자 권한도 가지고 있습니다.

엔터프라이즈 환경에서도 개별 사용자가 컴퓨터에 대해 관리자 권한을 가질 수 있습니다.

관리자 설정에는 다음 두 가지 유형이 있습니다.

■ mms.cfg 파일

■ Global Flash Player Trust 디렉토리

1.1. mms.cfg 파일은

Mac OS X 시스템인 경우 /Library/Application Support/Macromedia/mms.cfg에 있고,

Microsoft Windows 시스템인 경우 시스템 디렉토리의 Macromedia Flash Player 폴더에

있습니다

(예: 기본 Windows XP 설치인 경우 C:\windows\system32\macromed\flash\mms.cfg).

Flash Player를 시작하면 이 파일의 보안 설정을 읽어 기능을 제한하는데 사용합니다.

mms.cfg 파일에는 다음과 같은 작업을 수행하기 위해 관리자가 사용하는 설정이 포함되어

있습니다.

■ 데이터 로드 - 로컬 SWF 파일의 읽기를 제한하고 파일 다운로드 및 업로드를

비활성화하며 영구 공유 객체에 대한 저장 제한을 설정합니다.

■ 개인 정보 제어 - 마이크 및 카메라 액세스를 비활성화하고, SWF 파일에서

윈도우 없는 내용을 실행하지 않도록 하며, 브라우저 윈도우에 표시된 URL과 일치하지

않는 도메인의 SWF 파일에서 영구 공유 객체에 액세스하지 못하도록 합니다.

■ Flash Player 업데이트 - Flash Player의 업데이트 버전을 확인하는 간격을 설정하고,

Flash Player 업데이트 정보를 확인하고 해당 업데이트 버전을 다운로드할 URL을 지정하며,

Flash Player 전체에 대한 자동 업데이트를 비활성화합니다.

■ 이전 파일 지원 - local-trusted 샌드박스에 이전 버전의 SWF 파일을 배치할지

여부를 지정합니다.

■ 로컬 파일 보안 - 로컬 파일을 local-trusted 샌드박스에 배치할 수 있는지

여부를 지정합니다.

■ 전체 화면 모드 - 전체 화면 모드를 비활성화합니다.

SWF 파일은 Capabilities.avHardwareDisable 및 Capabilities.localFileReadDisable 속성을

호출하여 비활성화된 기능에 대한 일부 정보를 액세스할 수 있습니다.

그러나 mms.cfg 파일의 설정 대부분은 ActionScript에서 쿼리할 수 없습니다.

컴퓨터에 응용 프로그램과 무관한 보안 및 개인 정보 보호 정책을 적용하려면

시스템 관리자가 mms.cfg 파일을 수정해야 합니다.

응용 프로그램의 설치 관리자에서는 mms.cfg 파일을 사용할 수 없습니다.

관리자 권한으로 실행되는 설치 관리자는 mms.cfg 파일의 내용을 수정할 수 있지만,

Adobe는 이러한 사용을 사용자의 신뢰 위반으로 간주하고 설치 프로그램 작성자에게

mms.cfg 파일을 수정하지 않도록 권고합니다.

1.2. Global Flash Player Trust 디렉토리

관리자 및 설치 프로그램은 지정된 로컬 SWF 파일을 신뢰할 수 있는 파일로

등록할 수 있습니다.

이러한 SWF 파일은 local-trusted 샌드박스에 할당되며,

다른 SWF 파일과 상호 작용하고 원격이나 로컬의 모든 위치에서

데이터를 로드할 수 있습니다.

파일은 다음 위치에서 mms.cfg 파일과 동일한 디렉토리에 있는

Global Flash Player Trust 디렉토리에 신뢰할 수 있는 파일로 지정됩니다

(위치는 현재 사용자에 따라 다름).

■ Windows: system\Macromed\Flash\FlashPlayerTrust

(예: C:\windows\system32\Macromed\Flash\FlashPlayerTrust)

■ Mac: app support/Macromedia/FlashPlayerTrust

(예: /Library/Application Support/Macromedia/FlashPlayerTrust)

Flash Player Trust 디렉토리에는 텍스트 파일을 무제한으로 포함할 수 있으며

각 텍스트 파일에는 신뢰할 수 있는 경로가 한 줄에 하나씩 나열되어 있습니다.

각 경로는 개별 SWF 파일, HTML 파일 또는 디렉토리일 수 있습니다.

주석 행은 # 심볼로 시작됩니다.

예를 들어, 다음과 같은 텍스트가 포함된 Flash Player 신뢰 구성 파일은 지정된 디렉토리

및 모든 하위 디렉토리의 모든 파일에 대해 신뢰 상태를 부여합니다.

# Trust files in the following directories:

C:\Documents and Settings\All Users\Documents\SampleApp

신뢰 구성 파일에 나열된 경로는 항상 로컬 경로나 SMB 네트워크 경로여야 합니다.

신뢰 구성 파일의 모든 HTTP 경로는 무시되며, 로컬 파일만 신뢰할 수 있습니다.

충돌을 피하려면 각 신뢰 구성 파일에 설치 응용 프로그램에 해당하는 파일 이름을

부여하고 .cfg 파일 확장명을 사용합니다.

설치 프로그램을 통해 로컬로 실행되는 SWF 파일을 배포하려는 개발자의 경우,

설치 프로그램에서 Global Flash Player Trust 디렉토리에 구성 파일을 추가하도록 함으로써,

배포하는 파일에 전체 권한을 부여할 수 있습니다.

이때, 설치 프로그램은 관리자 권한이 있는 사용자가 실행해야 합니다.

mms.cfg 파일과 달리 Global Flash Player Trust 디렉토리는 신뢰 권한을 부여하기 위한

목적으로 설치 프로그램에 포함될 수 있습니다.

관리자와 설치 프로그램 모두 Global Flash Player Trust 디렉토리를 사용하여

신뢰할 수 있는 로컬 응용 프로그램을 지정할 수 있습니다.

2. 사용자 설정

Flash Player에서는 권한 설정에 대해 설정 UI, 설정 관리자 및 User Flash Player Trust

디렉토리의 서로 다른 세 가지의 사용자 수준 메커니즘을 제공합니다.

2.1. 설정 UI 및 설정 관리자

설정 UI는 특정 도메인의 설정을 구성하는 빠른 대화형 메커니즘입니다.

설정 관리자는 보다 자세한 인터페이스와 많은 도메인이나 전체 도메인의 권한에

영향을 주는 글로벌 변경 기능을 제공합니다.

또한 SWF 파일에서 새로운 권한을 요청할 때 보안 또는 개인 정보에 대해

런타임 의사 결정이 필요한 경우, 사용자가 일부 Flash Player 설정을 조정할 수 있는

대화 상자가 표시됩니다.

설정 관리자 및 설정 UI에서는 다음과 같은 보안 관련 옵션을 제공합니다.

■ 카메라 및 마이크 설정 - 사용자가 컴퓨터에서 카메라 및 마이크에 대한 Flash Player

액세스를 제어할 수 있습니다.

사용자가 전체 사이트 또는 특정 사이트에 대한 액세스를 허용하거나 거부할 수 있습니다.

사용자가 전체 사이트나 특정 사이트에 대한 설정을 지정하지 않은 경우,

SWF 파일에서 카메라나 마이크에 액세스하려고 하면, SWF 파일에서 해당 장치에

액세스하도록 허용할지 여부를 선택할 수 있는 대화 상자가 표시됩니다.

이때, 사용자는 사용할 카메라나 마이크를 지정하고 마이크의 민감도를 설정할 수 있습니다.

■ 공유 객체 저장 설정 - 도메인에서 영구 공유 객체 저장에 사용할 디스크 공간을

선택할 수 있습니다.

사용자는 특정 도메인에 대해 임의의 값을 설정하고 새로운 도메인에 대해

기본 설정을 지정할 수 있습니다.

기본 디스크 공간 제한 값은 100KB입니다.

2.2. User Flash Player Trust 디렉토리

사용자 및 설치 프로그램은 지정된 로컬 SWF 파일을 신뢰할 수 있는 파일로

등록할 수 있습니다.

이러한 SWF 파일은 local-trusted 샌드박스에 할당되며, 다른 SWF 파일과 상호 작용하고

원격이나 로컬의 모든 위치에서 데이터를 로드할 수 있습니다.

사용자는 다음 위치에서 Flash 공유 객체 저장 영역과 동일한 디렉토리에 있는

User Flash Player Trust 디렉토리에 신뢰할 수 있는 파일로 지정합니다

(위치는 현재 사용자에 따라 다름).

■ Windows: app data\Macromedia\Flash Player\#Security\FlashPlayerTrust

(예: C:\Documents and Settings\JohnD\Application Data\Macromedia\Flash

Player\#Security\FlashPlayerTrust)

■ Mac: app data/Macromedia/Flash Player/#Security/FlashPlayerTrust

(예: /Users/JohnD/Library/Preferences/Macromedia/Flash Player/#Security/

FlashPlayerTrust)

이러한 설정은 현재 사용자에게만 영향을 주며 컴퓨터에 로그인한

다른 사용자에게는 적용되지 않습니다.

관리자 권한이 없는 사용자가 시스템의 자체 소유 부분에 응용 프로그램을 설치한 경우,

설치 관리자에서 User Flash Player Trust 디렉토리에 이 응용 프로그램을 해당

사용자에 대해 신뢰할 수 있는 것으로 등록할 수 있습니다.

설치 프로그램을 통해 로컬로 실행되는 SWF 파일을 배포하는 개발자의 경우,

설치 프로그램에서 User Flash Player Trust 디렉토리에 구성 파일을 추가하도록 함으로써

배포하는 파일에 전체 권한을 부여할 수 있습니다.

3. 웹 사이트 설정(크로스 도메인 정책 파일)

웹 서버의 데이터를 다른 도메인의 SWF 파일에서 사용할 수 있도록 하기 위해 사용자 서버에

크로스 도메인 정책 파일을 작성할 수 있습니다.

크로스 도메인 정책 파일은 특정 또는 모든 도메인에서 제공되는 SWF 파일에서

해당 서버의 데이터나 문서를 사용할 수 있음을 나타내기 위해 사용되는 XML 파일입니다.

서버의 정책 파일에 지정된 도메인에서 제공되는 SWF 파일은 해당 서버의 데이터나

에셋에 대한 액세스가 허용됩니다.

크로스 도메인 정책 파일은 다음을 포함하여 많은 에셋에 대한 액세스에 영향을 줍니다.

■ 비트맵, 사운드 및 비디오 데이터

■ XML 및 텍스트 파일 로드

■ 소켓 및 XML 소켓 연결에 대한 액세스

■ 다른 보안 도메인의 SWF 파일을 로드하는 SWF 파일의 보안 도메인으로 가져오기

3.1. 정책 파일 구문

다음 예제는 *.example.com, www.friendOfExample.com 및 192.0.34.166에서 시작되는

SWF 파일에 대한 액세스를 허용하는 정책 파일을 보여 줍니다.

<?xml version="1.0"?>

<cross-domain-policy>

<allow-access-from domain="*.example.com" />

<allow-access-from domain="www.friendOfExample.com" />

<allow-access-from domain="192.0.34.166" />

</cross-domain-policy>

SWF 파일에서 다른 도메인의 데이터에 액세스하려고 하면 Flash Player는 자동으로

해당 도메인에서 정책 파일을 로드하려고 시도합니다.

액세스하려는 SWF 파일의 도메인이 정책 파일에 포함되어 있으면

자동적으로 데이터에 액세스할 수 있게 됩니다.

기본적으로 crossdomain.xml이라는 이름의 정책 파일이 해당 서버의 루트 디렉토리에

상주해야 합니다.

하지만 SWF 파일에서 Security.loadPolicyFile() 메서드를 호출하여 다른 이름 또는

다른 디렉토리 위치를 확인할 수 있습니다.

크로스 도메인 정책 파일은 정책 파일이 로드되어 있는 디렉토리와

해당 하위 디렉토리에만 적용됩니다.

따라서 루트 디렉토리에 있는 정책 파일은 전체 서버에 적용되지만 임의의

하위 디렉토리에서 로드된 정책 파일은 해당 디렉토리와 하위 디렉토리에만 적용됩니다.

정책 파일은 해당 파일이 상주하는 특정 서버에 대한 액세스에만 영향을 줍니다.

예를 들어, https://www.adobe.com:8080/crossdomain.xml에 있는 정책 파일은

8080 포트에서 HTTPS를 통해 www.macromedia.com에 수행된

데이터 로드 호출에만 적용됩니다.

크로스 도메인 정책 파일에는 0개 이상의 <allow-access-from> 태그가 포함된 단일

<cross-domain-policy> 태그가 들어 있습니다.

각 <allow-access-from> 태그에는 domain이라는 속성이 있습니다.

이 속성은 정확한 IP 주소, 정확한 도메인 또는

와일드카드 도메인(임의의 도메인)을 지정합니다.

와일드카드 도메인은 모든 도메인과 IP 주소를 나타내는 경우 단일 별표(*) 또는

특정 접미어로 끝나는 도메인을 나타내는 경우 접미어가 뒤에 붙은 별표로 표현됩니다.

접미어는 점으로 시작해야 합니다. 그러나, 접미어가 붙은 와일드카드 도메인은

앞에 오는 점을 제외한 접미어만으로 구성되는 도메인을 나타낼 수 있습니다.

예를 들어, foo.com은 *.foo.com에 속한 것으로 생각할 수 있습니다.

와일드카드는 IP 도메인 형식에 사용할 수 없습니다.

IP 주소를 지정하면 IP 구문(예: http://65.57.83.12/flashmovie.swf )을 사용하여

해당 IP 주소에서 로드된 SWF에만 액세스 권한이 부여됩니다.

이 경우 도메인 이름 구문을 사용하여 로드된 SWF에는 액세스 권한이 부여되지 않습니다.

Flash Player는 DSN 이름 확인을 수행하지 않습니다.

다음 예제와 같이 모든 도메인의 문서에 액세스할 수 있도록 허용할 수 있습니다.

<?xml version="1.0"?>

<cross-domain-policy>

<allow-access-from domain="*" />

</cross-domain-policy>

각 <allow-access-from> 태그에는 선택 사항인 secure 속성이 포함될 수 있으며

기본값은 true입니다.

정책 파일이 HTTPS 서버에 있을 경우 HTTPS가 아닌 서버의 SWF 파일이

HTTPS 서버에서 데이터를 로드할 수 있도록 허용하려면 이 속성을 false로 설정합니다.

secure 속성을 false로 설정하면 HTTPS에서 제공하는 보안 기능이 약화될 수 있습니다.

특히 이 속성을 false로 설정하면 보안 내용이 열려서 스누핑(snooping) 및 스푸핑(spoofing)

공격에 취약해집니다.

따라서 secure 속성을 false로 설정하지 않아야 합니다.

로드할 데이터가 HTTPS 서버에 있고, 해당 데이터를 로드하는 SWF 파일이 HTTP 서버에

있는 경우에는 로드하는 SWF 파일을 HTTPS 서버로 이동하여 HTTPS의 보호 하에

보안 데이터의 모든 복사본을 보관하는 것이 좋습니다. 그

러나 로드하는 SWF 파일을 HTTP 서버에 두기로 결정한 경우에는

다음 코드에 표시된 대로 secure="false" 속성을 <allowaccess-from> 태그에 추가합니다.

<allow-access-from domain="www.example.com" secure="false" />

정책 파일에 <allow-access-from> 태그가 없으면 서버에 정책이 없는 것과 동일한

결과가 발생합니다.

3.2. 소켓 정책 파일

ActionScript 객체는 문서 기반 서버 연결 및 소켓 연결의 서로 다른 두 종류의 서버 연결을

인스턴스화합니다.

Loader, Sound, URLLoader 및 URLStream과 같은 ActionScript 객체는 문서 기반 연결을

인스턴스화하며 각각은 URL에서 파일을 로드합니다.

ActionScript Socket 및 XMLSocket 객체는 소켓 연결을 만들어 로드된 문서가 아니라

스트리밍 데이터로 작업합니다.

Flash Player에서는 문서 기반 정책 파일과 소켓 정책 파일의 두 종류의 정책 파일을 지원합니다.

문서 기반 연결에는 문서 기반 정책 파일이 필요하고 소켓 연결에는

소켓 정책 파일이 필요합니다.

Flash Player에서는 정책 파일을 전송할 때 연결 시도에서 사용하려는 프로토콜과

동일한 프로토콜을 사용해야 합니다.

예를 들어, 정책 파일이 HTTP 서버에 있는 경우 다른 도메인의 SWF 파일은 HTTP 서버로

데이터를 로드할 수 있습니다.

하지만 동일한 서버에 소켓 파일을 제공하지 않으면 다른 도메인의 SWF 파일에서

소켓 수준의 서버에 연결할 수 없게 됩니다.

소켓 정책 파일을 가져올 때는 연결할 때와 같은 방법을 사용해야 합니다.

소켓 서버에서 제공하는 정책 파일은 액세스가 허용되는 포트를 지정해야 한다는 점을

제외하고 다른 정책 파일과 동일한 구문을 사용합니다.

1024보다 낮은 포트에서 제공되는 정책파일에서는 모든 포트에 액세스를 허용할 수 있고,

1024 이상의 포트에서 제공되는 정책 파일에서는 1024 이상의 포트에만

액세스를 허용할 수 있습니다.

허용되는 포트는 <allowaccess-from> 태그의 to-ports 속성에 지정됩니다.

단일 포트 번호, 포트 범위 및 와일드카드가 모두 허용되는 값입니다.

XMLSocket 정책 파일의 예는 다음과 같습니다.

<cross-domain-policy>

<allow-access-from domain="*" to-ports="507" />

<allow-access-from domain="*.example.com" to-ports="507,516" />

<allow-access-from domain="*.example2.com" to-ports="516-523" />

<allow-access-from domain="www.example2.com" to-ports="507,516-523" />

<allow-access-from domain="www.example3.com" to-ports="*" />

</cross-domain-policy>

정책 파일이 처음으로 Flash Player 6에 도입되었을 때는 소켓 정책 파일이 지원되지

않았습니다.

따라서 소켓 서버에 대한 연결은 소켓 서버와 동일한 호스트의 포트 80에 있는 HTTP

서버의 크로스 도메인 정책 파일의 기본 위치에 있는 정책 파일에 의해 허가되었습니다.

Flash Player 9에서는 기존의 서버 연결 방식을 보존하기 위해 이 기능을 지원합니다.

그러나 이제 Flash Player에서는 기본적으로 소켓 연결과 동일한 포트에 있는

소켓 정책 파일을 가져 옵니다.

HTTP 기반 정책 파일을 사용하여 소켓 연결을 허가하려면 다음과 같은 코드를 사용하여

명시적으로 HTTP 정책 파일을 요청해야 합니다.

Security.loadPolicyFile("http://socketServerHost.com/crossdomain.xml")

또한 소켓 연결을 허가하려면 HTTP 정책 파일을 다른 HTTP 위치가 아닌 크로스 도메인

정책 파일의 기본 위치에서 가져와야 합니다.

HTTP 서버에서 가져온 정책 파일은 암시적으로 1024 이상의 모든 포트에 대해

소켓 액세스를 허가하며 HTTP 정책 파일의 to-ports 속성은 무시됩니다.

3.3. 정책 파일 미리 로드

서버에서 데이터를 로드하고 소켓에 연결하는 것은 비동기식 작업으로,

Flash Player에서는 단순히 주요 작업을 시작하기 전에 크로스 도메인 정책 파일이

다운로드 되기를 기다립니다.

그러나 이미지에서 픽셀 데이터를 추출하거나 사운드에서 샘플 데이터를 추출하는 것은

동기식 작업으로, 데이터를 추출하기 전에 크로스 도메인 파일을 먼저 로드해야 합니다.

미디어를 로드하는 경우에는 다음과 같이 미디어에서 크로스 도메인 정책 파일을

확인하도록 지정해야 합니다.

■ Loader.load() 메서드를 사용하는 경우에는 LoaderContext 객체인 context 매개 변수

의 checkPolicyFile 속성을 설정합니다.

■ <img> 태그를 사용하여 텍스트 필드에 이미지를 포함하는 경우,

<img checkPolicyFile = "true" src = "example.jpg">와 같이 <img> 태그의

checkPolicyFile 속성을 "true"로 설정합니다.

■ Sound.load() 메서드를 사용하는 경우에는 SoundLoaderContext 객체인

context 매개변수의 checkPolicyFile 속성을 설정합니다.

■ NetStream 클래스를 사용하는 경우, NetStream 객체의 checkPolicyFile 속성을

설정합니다.

이 매개 변수 중 하나를 설정하는 경우에는 Flash Player에서 먼저 해당 도메인에서

이미 다운 로드한 모든 정책 파일을 확인합니다.

그리고 나서 Security.loadPolicyFile() 메서드에 대한 모든 대기 중인 호출을 검토하여

해당 범위 내에 있는지 확인하고 해당하는 경우 기다립니다.

그런 다음 서버의 기본 위치에서 크로스 도메인 정책 파일을 찾습니다.

4. 개발자 설정

보안 권한을 부여하는 데 사용되는 기본 ActionScript API는 Security.allowDomain()

메서드이며, 이 메서드를 사용하여 지정한 도메인의 SWF 파일에 권한을 부여합니다.

다음 예제에서는 SWF 파일이 www.example.com 도메인에서 제공되는 SWF 파일에 대한

액세스 권한을 부여합니다.

Security.allowDomain("www.example.com")

이 메서드는 다음과 같은 권한을 부여합니다.

■ SWF 파일 간 크로스 스크립팅

■ 표시 목록 액세스

■ 이벤트 감지

■ Stage 객체의 속성 및 메서드에 대한 전체 액세스

Security.allowDomain() 메서드를 호출하는 주요 목적은 도메인 외부에 있는 SWF 파일에

Security.allowDomain() 메서드를 호출하는 SWF 파일을 스크립팅할 수 있는 권한을

부여하는 것입니다.

Security.allowDomain() 메서드에 매개 변수로 IP 주소를 지정하더라도 지정된 IP 주소에

있는 모든 항목에 액세스가 허용되는 것은 아닙니다.

이때 해당 IP 주소에 매핑되는 도메인 이름이 아닌 URL에 지정한 IP 주소가 들어 있는

항목에만 액세스가 허용됩니다.

예를 들어,

도메인 이름 www.example.com이 IP 주소 192.0.34.166으로 매핑되는 경우

Security.allowDomain("192.0.34.166")을 호출해도 www.example.com에 액세스가 허용

되지 않습니다.

"*" 와일드카드를 Security.allowDomain() 메서드로 전달하여 모든 도메인에서의 액세스를

허용할 수 있습니다.

이렇게 하면 모든 도메인의 SWF 파일에 권한이 부여되어 호출하는 SWF 파일을

스크립팅하므로 "*" 와일드카드는 주의해서 사용해야 합니다.

ActionScript에는 Security.allowInsecureDomain()이라는 두 번째 권한 부여 API가

포함 되어 있습니다.

이 메서드는 Security.allowDomain() 메서드와 동일한 작용을 하지만,

보안 HTTPS 연결에 의해 제공되는 SWF 파일에서 이 메서드를 호출하는 경우에

HTTP와 같이 비보안 프로토콜에서 제공되는 다른 SWF 파일에 대해서도

호출하는 SWF 파일에 대한 액세스를 추가로 허용한다는 것이 다릅니다.

그러나 보안 프로토콜(HTTPS)의 파일과 비보안 프로토콜(HTTP 등)의 파일 간에

스크립팅을 허용하는 것은 보안상 안전하지 않습니다.

이렇게 하면 보안 내용이 열려 스누핑 및 스푸핑 공격에 취약해집니다.

이러한 공격의 작동방식은 다음과 같습니다.

Security.allowInsecureDomain() 메서드는 HTTP 연결을 통해 제공되는 SWF 파일에

대해 보안 HTTPS 데이터에 대한 액세스를 허용하므로 공격자가 HTTP 서버와

사용자 간에 끼어 들어 HTTP SWF 파일을 자신의 파일로 교체함으로써

HTTPS 데이터에 액세스할 수 있게 됩니다.

또 다른 중요한 보안 관련 메서드에는 Security.loadPolicyFile() 메서드가 있으며,

이를 통해 Flash Player는 비표준 위치에서 크로스 도메인 정책 파일을 확인합니다.

아래 예제에서는 Sprite 객체의 click 이벤트를 사용하여 Flash Player 설정의

[로컬 저장 설정] 패널을 표시합니다.

실행 후 주황색 박스를 클릭하면, Flash Player에서

해당 [로컬 저장 설정] 패널이 열릴 것입니다.

//SecurityExample.as

package {

import flash.display.Sprite;

import flash.text.TextField;

import flash.events.*;

import flash.system.Security;

import flash.system.SecurityPanel;

public class SecurityExample extends Sprite {

private var bgColor:uint = 0xFFCC00;

public function SecurityExample() {

draw();

}

private function draw():void {

var child:Sprite = new Sprite();

child.graphics.beginFill(bgColor);

child.graphics.drawRect(0, 0, 100, 80);

child.graphics.endFill();

child.buttonMode = true;

var label:TextField = new TextField();

label.text = "로컬 저장\n설정 패널\n열기\n\n여기를 클릭";

label.selectable = false;

label.mouseEnabled = false;

child.addChild(label);

child.addEventListener(MouseEvent.CLICK, clickHandler);

addChild(child);

}

private function clickHandler(event:MouseEvent):void {

Security.showSettings(SecurityPanel.LOCAL_STORAGE);

}

//Security.fla

var security:SecurityExample = new SecurityExample();

addChild(security);

로컬 Flash 내용이 인터넷과 통신할 수 있게 하는 방법입니다.

Macromedia Flash Player 8 이상 버전에서 특정 형식의 로컬 내용은 사용자 컴퓨터에 저장된

데이터에 액세스할 수 없고 사용자의 승인 없이 내용을 인터넷으로 보낼 수 없도록 제한됩니다.

Flash Player 설정 관리자를 사용하여 신뢰하는 내용을 인터넷과 통신하도록 허용할 수 있습니다.

로컬 내용이 차단되는 이유

로컬 내용에 대한 Flash Player 보안 기능에서는 로컬 컴퓨터에 저장된 특정 종류의 내용에

대해 권한을 부여하지 않은 경우 네트워크 통신을 제한합니다.

이 보안 조치는 사용자의 컴퓨터나 로컬 네트워크에 저장된 중요한 정보를 인터넷으로

보내는 데 사용될 수 있는 안전하지 않을 수 있는 내용으로부터 사용자를 보호합니다.

이 보안 조치로 인해 때때로 현재 사용하고 있으며 안전한 것으로 확인된

Flash 내용이 제대로 작동하지 못할 수 있습니다.

이 문제는 내용을 신뢰하도록 지정하여 해결할 수 있습니다.

Flash Player에서 신뢰하는 것으로 지정된 내용은 컴퓨터에 액세스하고 인터넷과 통신할 수 있습니다.

보려는 내용을 신뢰할 수 있는 경우에만 신뢰하는 것으로 지정하십시오

로컬 내용이 인터넷과 통신하도록 허용

Flash Player 보안 경고 대화 상자(그림 1)를 표시하여 신뢰할 수 없는 응용 프로그램이

인터넷과 통신하려고 시도했기 때문에 Flash Player에서 이 프로그램을 차단했음을 알립니다.

응용 프로그램을 확인하고 이 응용 프로그램이 인터넷에 액세스하도록 허용하려면

Flash Player 설정 관리자를 사용하여 인터넷과 통신할 수 있도록 신뢰하는 내용 목록에 이 내용을 추가합니다.

Flash Player 보안 경고 대화 상자가 나타나는 경우:

1. 설정(그림 1)을 클릭하여 설정 관리자의 전역 보안 설정 패널로 이동합니다.

확인을 클릭하여 대화 상자를 닫습니다.

그러나 Flash Player에서 내용을 계속 차단합니다.

그림 1. 로컬 내용이 인터넷에 연결하려고 할 때 로컬 파일 보안 경고가 나타납니다.

2. 편집(그림 2)을 클릭하여 드롭다운 메뉴에 액세스한 다음 추가를 선택합니다.

나타나는 대화 상자에서 신뢰하는 파일과 위치 목록에 내용을 추가할 수 있습니다.

그림 2. 설정 관리자의 전역 보안 설정 패널

3. 파일 또는 디렉터리를 로컬 컴퓨터에 추가하려면 이 위치 신뢰 상자에 내용 위치를 입력합니다.

보안 대화 상자의 설정 단추를 클릭하여 전역 보안 설정 대화 상자에 액세스한 경우

컴퓨터의 내용 위치를 보여주는 힌트가 나타납니다(그림 3).

텍스트 상자에 위치를 복사하여 붙여 넣을 수 있습니다.

그런 다음 확인을 클릭하여 신뢰하는 위치 목록에 위치를 추가합니다.

또는 Browse for Files나 Browse for Folder를 클릭하여 파일 선택기를 열어 신뢰 목록에

추가하고 싶은 파일 또는 폴더를 탐색할 수도 있습니다.

파일이나 폴더를 선택한 후에 확인을 클릭하여 위치를 적용합니다.

그림 3. 보안 대화 상자의 설정 단추를 클릭하여 전역 보안 설정 대화 상자에

액세스한 경우 컴퓨터의 내용 위치를 보여주는 힌트가 나타납니다.

4. 이제 선택된 위치가 신뢰하는 위치 목록에 나타납니다.

이제 설정 관리자를 닫고 내용이나 응용 프로그램으로 돌아갑니다.

새 설정을 적용하려면 브라우저에서 내용을 새로 고치거나 응용 프로그램을

다시 시작해야 합니다.

그림 4. 이제 선택된 위치가 신뢰하는 위치 목록에 나타납니다.

이미 신뢰하는 내용에 대해 로컬 파일 보안 경고가 나타나는 이유

위의 단계를 수행했지만 이미 신뢰하는 특정 내용에 대해 Flash Player 보안 경고가 나타나는 경우:

신뢰 목록에 더 많은 파일을 추가해야 할 수도 있습니다.

일부 응용 프로그램은 SWF 파일 및 HTML 페이지와 같은 여러 파일로 구성되어 있습니다.

인터넷과 통신하려는 각 파일은 신뢰하는 파일로 설정되어 있어야 합니다.

내용이나 응용 프로그램이 있는 디렉터리 전체를 신뢰하는 것이 좋습니다.

예를 들어 인터넷과 통신하려는 파일이 C:/SampleApp/sampleApp.swf에 있는 경우

디렉터리의 모든 파일을 신뢰하도록 C:/SampleApp 디렉터리를 추가할 수 있습니다.

단, 디렉터리 및 하위 디렉터리의 모든 내용을 신뢰하는 경우에만 전체 디렉터리를

신뢰하는 목록에 추가해야 합니다.

C:/와 같은 최상위 디렉터리는 신뢰하는 것으로 지정하지 마십시오.

신뢰 목록에 추가한 경로가 잘못 입력되었거나 정확하지 않습니다.

브라우저 주소 표시줄에 경로를 직접 입력하고 그 위치에 해당 내용이 있는지 확인하여

추가한 경로가 내용을 확실히 가리키는지 확인할 수 있습니다.

신뢰 목록에 내용을 추가한 후 내용이 옮겨졌습니다.

내용을 신뢰하는 위치 목록에 추가한 후 내용을 옮긴 경우 Flash Player에서 등록된

경로는 더 이상 올바른 위치를 가리키지 않습니다.

이 서비스 문서에서 설명하는 단계를 수행하여 새 위치를 추가합니다.

실수로 다른 내용을 신뢰하는 것을 방지하려면 이전 위치를 제거하는 것도 좋습니다.

[출처] 플래시 보안정책 (게임 제작 마스터) |작성자 원더걸스

=================================

Security Domains, Application Domains, and More in ActionScript 3.0

http://www.senocular.com/flash/tutorials/contentdomains/

DateLanguageTarget

October 23, 2010

ActionScript 3.0

Flash Player 9+

Introduction

If you haven't yet had to bother with the complexities around security domains or application domains, consider yourself lucky. Even if you've loaded external content in the past (which is when they come into play), the defaults probably worked well enough for you then not to have to worry about what they do or mean.
But sometimes you will need a little more. You'll want to have more control over behavior, or enable functionality that's not possible using the default settings. Maybe there's some external content that you're having trouble accessing. Or maybe you're just confused about the difference betweenSecurity.allowDomain and crossdomain.xml files or want to know about best practices around security. If so, you're in the right place.
The following tutorial will cover what security and application domains are and how they're used in Flash Player, both in terms of providing functionality as well as protection through security.
Table of ContentsPage 1

Page 2

Sandboxing

Sandboxing the process of separating groups of data and/or code execution from one another. Sandboxes are especially important in security where, without the appropriate trust, two separate pieces of content should not be able to interact with each other when they shouldn't. Flash Player's security model uses sandboxes known as security domains to separate content this way.
Though security is a primary case for sandboxing, it may not be the only reason. You may also want to sandbox two pieces of content to prevent conflicts with overlapping naming schemes. Keeping them separate allows them to function normally, avoiding any conflict that might have occurred as a result of bringing them together. This separation is handled through Flash Player by sandboxes known as application domains.

Security Domains

Security domains in Flash are the top level sandboxes. Security domains link themselves to a content's source domain, or the domain from which content (e.g. a SWF) was loaded. A SWF hosted on the senocular.com would have a security domain linked to the senocular.com domain, while a SWF being hosted on example.com would have a separate security domain linked to the example.com domain name. Having two separate security domains causes the each of the SWFs to be run in their own sandboxes within Flash Player.

Security domain sandboxes in Flash Player

Note: About the ExamplesFor examples in this tutorial, you'll see subdomains of the same top-level domain (example.com, to protect the innocent) used to represent different domains. In Flash, different subdomains are seen as different as different top-level domains. Example code will also be simplified though complete enough that they should mostly work when used as timeline scripts within the Flash Professional authoring tool.

Non-executable (non-SWF) content, such as image or text files, is also separated into security domains, again using their source domains as the determining factor as to which security domain they belong. These domains determine how accessibility the content is or even whether the content can be loaded at all. More on that is covered in the Non-executable Trust section.
For SWFs, security domains separate both data and code execution. Data (e.g. variables) in one SWF cannot inherently be accessed by another SWF if they exist in separate security domains. Both their data, and the code they execute, are cut off from one another in a way that prevents interaction. Attempting to access data in another security domain will create a security error.
The following code shows a SWF which attempts to load another SWF - whose contents are irrelevant - and access its document class instance (main timeline).

http://same.example.com/parent.swf:

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.INIT, init);

var url:String = "http://diff.example.com/child.swf";
loader.load(new URLRequest(url)); 

function init(event:Event):void {
 trace(loader.content);
 // SecurityError: Error #2121: Security sandbox violation:
 // Loader.content: http://same.example.com/parent.swf
 // cannot access http://diff.example.com/child.swf.
 // This may be worked around by calling Security.allowDomain.
}

Any attempt of accessing the loaded SWF's content, even tracing theLoader.content property as seen above, will fail creating a security error if dealing with content in different security domains.
The separation between security domains also extends into the native ActionScript class definitions in Flash Player that are used by all SWFs. Different copies of these classes exist in each security sandbox created by Flash. For example, the native XML class in one security domain is not the same as the XML class in another. If a SWF in one security domain changes the static class property XML.prettyIndent, it would not be reflected in other security domains.
Consider the following SWF which loads two SWFs from two different domains, one from its own domain and one from another. Each of the child SWFs checks the value of prettyIndent after it's been changed by the parent.
http://same.example.com/parent.swf:

trace(XML.prettyIndent); // 2
XML.prettyIndent = 5;
trace(XML.prettyIndent); // 5

// Same domain:
var sameLoader:Loader = new Loader();
var sameURL:String = "http://same.example.com/child.swf";
sameLoader.load(new URLRequest(sameURL)); 

// Different domain:
var diffLoader:Loader = new Loader();
var diffURL:String = "http://diff.example.com/child.swf";
diffLoader.load(new URLRequest(diffURL));

http://same.example.com/child.swf:

trace("same: " + XML.prettyIndent); // same: 5

http://diff.example.com/child.swf:

trace("diff: " + XML.prettyIndent); // diff: 2

When tracing out the value of static class property XML.prettyIndent (whose default value is 2), you can see that the SWF originating from the other domain did not reflect the changes made to the property while the SWF in the same domain did. Each security sandbox was given its own copy of the native ActionScript class definitions.

Trust

Though security domains are inherently sandboxed from one another, expressing trust can open up a line of communication or the sharing of data between two different SWFs in two different security domains. With trust, code executing in one security domain can access data and call methods in another almost as though it was part of the same security domain.
In ActionScript, trust is given to a SWF in a different security domain usingSecurity.allowDomain (and the similar Security.allowInsecureDomain). This is a function that code in the trusting security domain must call to grant trust to another, or group of other domains based on their source domain names. Once executed, code in the trusted domain can script freely within the content of the SWF that demonstrated trust. This only works one way; the SWF callingallowDomain won't be able to access the other SWF unless it too makes the appropriate call to allowDomain.

Security domains with trust

Consider the following example where a child SWF calls allowDomain to trust its parent:
http://home.example.com/parent.swf:

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.INIT, init);

var url:String = "http://away.example.com/child.swf";
loader.load(new URLRequest(url));

function init(event:Event):void {
 // (allowDomain has been called by child)
 trace(loader.content); // [object DocumentClass]
}

http://away.example.com/child.swf:

Security.allowDomain("home.example.com");

Without trust, as seen before, access to the content of the child SWF would throw an error. But once the loaded SWF has called allowDomain, the parent can access its content and other data freely. Note that with this example, the child SWF still does not have access to the loader's content since the parent SWF did not express trust towards away.example.com in its own call to allowDomain.
Trust is an important security concept to understand, and should not be taken lightly. Often it may seem easiest to use the wildcard (*) trusting every SWF using:

// BE CAREFUL!

Security.allowDomain("*");

Doing so grants any SWF - not just SWFs you load since other SWFs could load yours - access to your data and functions in ActionScript. Though you may not directly expose any sensitive data, if you have any functions that could be used to get such data, they could be abused by a trusted SWF. Trust given throughallowDomain gives other SWFs a kind of anything you can do, I can do access. Later, in the Merging Security Domains section, you'll see it can actually mean more.
If you need to allow SWF to SWF communication but don't want to trust SWFs enough to allow trust to their domains, you're not completely out of luck. In theSWF Communication Without Trust section, we'll look out how thesharedEvents object can be used to bridge this gap.

Non-executable Trust

Trust for non-executable (non-SWF) content has to be handled differently by Flash Player since that content cannot execute calls to allowDomain for express explicit trust. This is where Flash Player uses cross-domain policy files.
Cross-domain policy files are XML files - typically named crossdomain.xml on the root of a web domain - that, similar to allowDomain, define a list of web domains (among other things) that are trusted to load content on the server by Flash Player. The following is what a simple cross-domain policy file may look like:
http://example.com/crossdomain.xml:

<?xml version="1.0"?> 
<cross-domain-policy>
 <site-control permitted-cross-domain-policies="by-content-type"/>
 <allow-access-from domain="*.example.com"/>
 <allow-access-from domain="www.example-partner.com"/>
</cross-domain-policy>

You can read more about the policy file format from the Cross-domain policy file specification (adobe.com).
Unlike allowDomain, cross-domain policy files provide a blanket trust, trusting more than one file - usually all files on a domain - rather than single files on an individual basis. This makes allowDomain a stronger solution than cross-domain policy files in that sense, but Flash Player can't expect content like text, images, and sounds to somehow identify domain-specific trust within their own data. So as an alternative, Flash Player looks to a single cross-domain policy file when trust for such content on a domain is necessary. The sample cross-domain policy file above allows SWFs located on any subdomain of example.com orwww.example-partner.com to load and read data from any file located on theexample.com domain.
Policy files don't usually provide trust to SWFs because they already have a mechanism for doing that through allowDomain. Loading a SWF into another SWF will always work regardless if there is a policy file or not. There is one exception, when merging a cross-domain SWF into your own security domain. More on that will be covered in the Merging Security Domains section.
When, and only when, a cross-domain policy file is needed, Flash Player automatically finds and downloads it from the domain that's part of the original request that requires it. This applies to both the standard policy file location with crossdomain.xml at the domain root as well as any specific policy file location specified by Security.loadPolicyfile. At the point in time when the content is loaded, policy files are also loaded, grouped in with the loading process of the content.
Once loaded, Flash Player analyzes a policy file's tags to see if the hosting domain trusts the domain hosting the SWF with its content. If the domain trusts the SWF's domain, the content is loaded normally and can be used as if it were hosted on the same domain as the SWF. If not, one of two things will happen:

The content doesn't load or
The content loads, but its data cannot be accessed directly by the loading SWF

If the content being loaded is strictly data (text, XML, arbitrary binary data, etc.) the content won't load at all if not trusted. There wouldn't be any point since it couldn't be accessed or serve any purpose if it was.

Policy file needed to load data-only content

However, if the content can still have purpose without the SWF having access to reading its data (images, sounds, etc.) then the content will load but only in a context in which it will be visible (or audible) to the user. Images, for example, can be displayed in Loader objects for a user to see, however without trust from a cross-domain file from the hosting domain, operations like BitmapData.drawwould fail if attempted on that image as it would mean providing the SWF with image data.

Policy file needed to access data of other content

This may be a little confusing since the user is still allowed to access the content but the SWF is not. There's a number of different security implications that have to be considered when Flash Player is running a SWF. In the end, it ultimately comes down to protecting data - the user's data, and the data they have access to - from a potentially malicious SWF that would steal and abuse that data. It's not so much about preventing what the user of a SWF has access to. User's, for example, don't need to worry about cross-domain policy files to look at content on the web normally.
This doesn't mean cross-domain policy files should be taken lightly. A lot of damage can be done by a domain that uses a permissive cross-domain file like the following:

<?xml version="1.0"?> 
<cross-domain-policy>
 <!-- BE CAREFUL! -->
 <allow-access-from domain="*"/>
</cross-domain-policy>

Warning: What it means to allow access to all domains with the wildcard (*) in a cross-domain policy file like this: All data on the domain that any user could potentially access at any point in time can also be potentially accessed by any SWF anywhere.
As a client-side application Flash Player runs under the authentication of the current user. This means user data is potentially Flash Player's data. And Flash Player's data is potentially the data accessible by any SWF that runs in it. By default Flash Player restricts cross-domain content loading for the very reason that it can't know what the SWF should have access to and what it shouldn't, assuming the only safe data is data on the same domain as the SWF. Without this restriction, a SWF could get and do whatever it wanted with any data the current user has access to.
Consider a user that uses a web mail client (in the browser) to check their email. To access their email, the user logs on to the site with the necessary credentials. The user then opens a new tab in their browser to a web site that has a malicious SWF out to steal the user's data. Without cross-domain data protection, this SWF could load in the URL used to display the users messages and read them directly without the user even knowing, all by using his or her existing credentials. The same applies to any intranet site accessible to the user as well; whatever the user can get to, so can a SWF. Instead, Flash Player blocks this data unless the domain explicitly trusts SWFs to access it through policy files.
As a rule, you should avoid having a cross-domain policy file on any domain that contains sensitive data, even (especially) if user authentication is needed to access that data. Should you need to serve data that needs to be consumed by remote SWF files, host that data on a separate domain or subdomain.

DomainDescriptionPolicy file

login.example.com	Hosts user data	None
feed.example.com	Hosts public data	Includes: <allow-access-from domain="*" />

This keeps sensitive data inaccessible, but still allows SWFs from other domains to consume data you wish to be publicly available.

Non-executable Content Without Trust

Without trust through cross-domain policy files, Flash Player strictly blocks non-SWF content. This is especially true for data-only types such as text; they don't even load into the player. If you need content from a domain that you do not have control of and that does not have, nor will allow a cross-domain policy file trusting your domain, then you are out of options for obtaining that data on the Flash Player side of things. A server-side solution, however, is a possible remedy.
Policy files are designed to protect data, specifically to protect the user's data, or at least data accessible by the user. This data is accessible because of Flash Player's rights in the user space. Server-side code execution, on the other hand, does not have these same privileges. Server-side code is executed in the server space, in fact on a completely different machine from the user, so user access is irrelevant when a server is used to obtain data.
Because servers do not have the user's privileges, server code can load data from any freely accessible web location without being bound by the same cross-domain restrictions used by Flash Player. This means a server-side script on the host of a SWF can be used to load content from another domain and then present that to the SWF in the same domain. As same-domain content, Flash Player wouldn't require a policy file. The content simply appears to be from the same domain as the SWF because of a server-side page was able to load it from another domain and present it to the SWF as it's own.
The following ActionScript shows an example how of this might work for a server-side php script in its own domain that loads and displays data from another.
http://home.example.com/loader.swf:

var urlLoader:URLLoader = new URLLoader();

var urlVariables:URLVariables = new URLVariables();
// custom variable used by server page to know
// what remote site to load data from
urlVariables.externalURL = "http://away.example.com/content.txt";

// custom server script reading data from
// externalURL passing it through to it's
// output to be read by this SWF
var serverPage:String = "http://home.example.com/read.php";

var request:URLRequest = new URLRequest(serverPage);
request.data = urlVariables;
urlLoader.load(request);

There are a couple of problems with this approach. For one, it requires that you have access to and write code for a server-side environment. This may be a hassle if working with a smaller project that has had, up until that point, no server-side requirements, or if you have no control over your hosting options.
Maybe more importantly, by tunneling the data through your own server, you're doubling the amount of web traffic needed to serve the file. First, the file is downloaded from the original domain onto your server. Then the file is downloaded from your server into the Flash Player client SWF. Not only does this increase web traffic in general, it's putting load on your own server where otherwise, with a trusting cross-domain file, there would have been none.
Regardless, this is often a solution, and a perfectly secure one, used to get past cross-domain policy files used by Flash Player.

SWF Communication Without Trust

There may be times when you want to communicate with another SWF in another security domain, possibly from an unknown or unreliable source, but you don't want to fully trust that domain, granting it full access to your content data. The LoaderInfo class actually offers a mechanism for doing that through a property called sharedEvents. The sharedEvents object is a single, trusted EventDispatcher object defined in a LoaderInfo that is shared between security domains. Both the SWF loader and the loaded SWF can access this object and dispatch and listen for events to and from one another.
Events dispatched through the sharedEvents object are "blessed" and become fully trusted in both domains. This allows any arbitrary data to be passed back and forth between different security domains without concern for security violations.
Warning: Be careful; pass the wrong data through the sharedEvents object and you can completely open up your SWF to the other SWF on the receiving end. Specifically, if an event happens to carry a reference to any "connected" object, especially anything that might be on the display list, your entire SWF would be exposed to cross-domain scripting.
Events dispatched through sharedEvents should be limited to event types that contain only simple data, thereby preventing any chances that the other SWF could find a backdoor into scripting your SWF through some deep reference. If more complex events types are needed, they should be cleaned before they're passed through.
When using the sharedEvents object, each SWF would have to make sure that they send and receive unique event types since both SWFs reference the same instance. The parent SWF would dispatch events of one type and listen for events of a different type. The child SWF would listen for the event types dispatched by the parent and dispatch those the parent is listening for. Names for these event types are completely up to you.
The following example uses sharedEvents to communicate simple text messages between parent and child SWF in different security domains. The parent dispatches events of the type "fromParent" while the child uses "fromChild".
http://safe.example.com/parent.swf:

var loader:Loader = new Loader();
var shared:EventDispatcher = loader.contentLoaderInfo.sharedEvents;
shared.addEventListener("fromChild", fromChild);

var url:String = "http://untrusted.example.com/child.swf";
loader.load(new URLRequest(url));

function fromChild(event:TextEvent):void {
 trace(event.text); // Good day
 
 var replyMessage:TextEvent = new TextEvent("fromParent");
 replyMessage.text = "Same to you";
 shared.dispatchEvent(replyMessage);
}

http://untrusted.example.com/child.swf:

var shared:EventDispatcher = loaderInfo.sharedEvents;
shared.addEventListener("fromParent", fromParent);

var firstMessage:TextEvent = new TextEvent("fromChild");
firstMessage.text = "Good Day";
shared.dispatchEvent(firstMessage);
 
function fromParent(event:TextEvent):void {
 trace(event.text); // Same to you
}

Any kind of event can be used for passing information back and forth this way, event custom events. Again, just be careful not to pass along event data that could contain references to other, more sensitive objects, especially not objects on the display list. An example of handling this can be found in the Stage Owner and Access section.

Merging Security Domains

If trust exists between two domains, a SWF on one of the domains has the option of loading a SWF from the other domain into its own security domain. This would be equivalent to loading a SWF as if it were on the same domain.
Trust is handled slightly different in this case. First off, for the domain of the parent SWF, nothing specific needs to be done to express trust. The simple act of attempting to load another SWF in your own security domain means that you are already committing to fully trusting the contents of that SWF.
Secondly, because the child SWF is immediately being loaded into the security domain of the loader, it has no opportunity to express trust through allowDomain, since by the time it has a chance to call it, it has already been instantiated within the other domain's security domain. Trust has to be expressed before the SWF even loads. For this, the cross-domain policy file is used. This is, in fact, the only time when a cross-domain policy file is used to grant trust to a SWF.

Policy files needed to for loading cross-domain SWFs in the same security domain

To load another SWF into the security domain of your own, you would need to callLoader.load with an instance of a LoaderContext object. The securityDomainproperty of that LoaderContext is set to a reference to the current security domain. This is accessible through SecurityDomain.currentDomain. In setting this value, the loader SWF expresses trust in the SWF that is to be loaded, while that SWF expresses trust through a policy file.

http://host.example.com/parent.swf:

trace(new LocalConnection().domain); // host.example.com

var loader:Loader = new Loader();

// create a LoaderContext that indicates that
// the loaded SWF will be loaded into this
// security domain
var context:LoaderContext = new LoaderContext(true);
context.securityDomain = SecurityDomain.currentDomain;

var url:String = "http://trusting.example.com/child.swf";
loader.load(new URLRequest(url), context);

http://trusting.example.com/crossdomain.xml:

<?xml version="1.0"?> 
<cross-domain-policy>
 <allow-access-from domain="host.example.com"/>
</cross-domain-policy>

http://trusting.example.com/child.swf:

trace(new LocalConnection().domain); // host.example.com

Using the domain property of a LocalConnection instance, the security domain is checked for each SWF. Though the child SWF originated from thetrusting.example.com domain, it's shown as being within thehost.example.com domain because the parent SWF loaded it into its own security domain.
The trust given to a SWF loaded into the current security domain goes beyond that given through allowDomain. Whereas with allowDomain you're effectively giving a SWF anything you can do, I can do permissions, when loading a SWF into the same security domain, you give them permissions along the lines of I can do anything. In the prior case, a SWF can only call into your code, limited by what your SWF defines. But when loaded into the same security domain, their SWF has no limitations and can do anything SWFs are capable of doing, and doing so within the context of your domain. This includes:

Access to everything in the loader SWF
Reading all files served on the domain
Reading all files served on other domains that trust the domain
Reading shared object data specific on the domain
Access to local connection communications made to through the domain
Access to socket connections trusting the domain

Before introducing a cross-domain SWF into your own security domain, you should be sure that you trust them enough to use and not abuse this power.
Using load with a LoaderContext with your security domain is not the only way to have content load into your own security domain. The Loader class also supports another method for loading content called loadBytes. Unlike load, it does not use a URL to load remote content. Instead, it loads content through data already present in SWF in the form of a ByteArray.
Because loadBytes has no way to associate its loaded content with a domain - ByteArrays, after all, do not retain any kind of domain association - content loaded through loadBytes is always loaded into the current security domain. This is usually safe enough since to get a hold of those bytes to begin with, you'd have to have some kind of trust to do so.
http://host.example.com/parent.swf:

trace(new LocalConnection().domain); // host.example.com

var loader:Loader = new Loader();

var urlLoader:URLLoader = new URLLoader();
urlLoader.dataFormat = URLLoaderDataFormat.BINARY;
urlLoader.addEventListener(Event.COMPLETE, bytesLoaded);

// cross-domain policy file required to load data
var url:String = "http://trusting.example.com/childbytes.swf";
urlLoader.load(new URLRequest(url));

function bytesLoaded(event:Event):void {
 loader.loadBytes(urlLoader.data);
}

http://trusting.example.com/crossdomain.xml:

<?xml version="1.0"?> 
<cross-domain-policy>
 <allow-access-from domain="host.example.com"/>
</cross-domain-policy>

http://trusting.example.com/childbytes.swf:

trace(new LocalConnection().domain); // host.example.com

As seen with Loader.load with a LoaderContext specifying the current secuirty domain, loadBytes too, will load content into the same security domain as seen by LocalConnection.domain for the child SWF.
Warning: There is one slight security flaw in the loadBytes method. This deals with the differences between a trusted SWF in another domain and a SWF loaded into your own domain. Though both are trusted, there's no doubt a SWF in the same security domain can do a lot more than a trusted SWF in another domain (as listed above). It's the difference between anything you can do, I can do and I can do anything. The difference being, there's actually no difference.
With trust, a loaded SWF - even in another security domain - has complete access to everything within the loader SWF, including the Loader instance that was used to load it. With access to the loader comes access to loadByteswhich means suddenly the trusted child SWF has the power to load arbitrary binary content in the loader SWF's own security domain. In the end, trusting a SWF can be just as dangerous as loading it into your own security domain since it can load content into your security domain just by being loaded at all.
The following example shows just how this can work:
http://good.example.com/parent.swf:

// "you can do I can do" trust only
Security.allowDomain("evil.example.com");

// should be protected
var so:SharedObject = SharedObject.getLocal("foo", "/");
so.data.foo = "bar";
so.flush();
 
var loader:Loader = new Loader();
var url:String = "http://evil.example.com/child.swf";
loader.load(new URLRequest(url));

http://evil.example.com/child.swf:

var so:SharedObject = SharedObject.getLocal("foo", "/");
trace("trust only: " + so.data.foo); // trust only: undefined

var urlLoader:URLLoader = new URLLoader();
urlLoader.dataFormat = URLLoaderDataFormat.BINARY;
urlLoader.addEventListener(Event.COMPLETE, bytesLoaded);

var url:String = "http://evil.example.com/childbytes.swf";
urlLoader.load(new URLRequest(url));
 
function bytesLoadedEvent):void {
 // THREAT! loadBytes to load SWF data into
 // security domain of trusting parent SWF
 loaderInfo.loader.loadBytes(urlLoader.data);
}

http://evil.example.com/childbytes.swf:

var so:SharedObject = SharedObject.getLocal("foo", "/");
trace("same domain: " + so.data.foo); // same domain: bar

This behavior may be changed in future releases of Flash Player, so you shouldn't build applications around it. Instead, focus more on the threat of what this means when loading and trusting SWF content from other sites: complete access to all of your domain's data.

Stage Owner and Access

When a SWF is first loaded into Flash Player, it is added to the display list of the player under the top-most object known as the stage. This is the root display object of Flash Player itself. Each SWF also has it's own root (called root) which represents the instance of its document class or its main timeline. The SWF that instantiated Flash Player has its root placed in the stage while other child SWFs are loaded as children of the Loader instances used to load them.
The stage is special in that, though it is itself technically accessible by all SWFs on the display list as a part of that display list, it only has one owner. Ownership of the stage is given to the SWF that first instantiated Flash Player - the SWF whose root is immediately placed in the stage instance. The stage owner defines the security domain in the stage is linked. Other SWFs wishing to use the stage for specific purposes would have to be either loaded into the security domain of the stage owner or have it's security domain trusted by it.
You may have noticed in the past that some applications, or maybe just components in them, have failed to function properly when loaded into another SWF from a different (untrusted) domain. This is happens because code there presumes to have permission to use the stage object when they don't. This can be tricky to grasp at first since the stage object itself is accessible, but calling certain stage methods like addEventListener is not.
The following list shows what Stage members are restricted when accessed from a security domain other than the stage owner's. This list may not be 100% accurate, so only use it as a guide.

addChild	addChildAt	removeChild
removeChildAt	getChildIndex	setChildIndex
getChildAt	getObjectsUnderPoint	swapChildren
swapChildrenAt	numChildren	tabChildren
mouseChildren	width	stageWidth
fullScreenWidth	height	stageHeight
fullScreenHeight	quality	align
scaleMode	displayState	fullScreenSourceRect
stageFocusRect	showDefaultContextMenu	colorCorrection
addEventListener	dispatchEvent	hasEventListener
willTrigger

Watch how, in the example below, while stage is accessible from the child SWF, calls to stage.addEventListener are not permitted.
http://first.example.com/parent.swf:

var loader:Loader = new Loader();
addChild(loader);

var url:String = "http://second.example.com/child.swf";
loader.load(new URLRequest(url));

http://second.example.com/child.swf:

// Works
trace(stage); // [object Stage]

// Does not work
stage.addEventListener(MouseEvent.CLICK, stageClick);
// SecurityError: Error #2070: Security sandbox violation: 
// caller http://second.example.com/child.swf cannot access 
// Stage owned by http://first.example.com/parent.swf.

Stage ownership is especially painful in terms of events since the stage object is often the target for keyboard and mouse events when globally detecting key presses or recognizing when the mouse is released outside of an object. For a child SWF alone in this situation, there's not a whole lot that can be done. However, a parent SWF owning the stage does have the option to pass stage events through the sharedEvents without having to fully commit to trusting the child. This would allow the child SWF to receive the necessary events while still protecting the parent. Both SWFs would have to coordinate on making this work.
Warning: This use case is a prime example of how sharedEvents security can be compromised. Certain mouse events reference timeline objects through therelatedObject property. If a mouse event with that property defined is passed through sharedEvents, it would allow the receiving SWF to freely access timeline objects in the untrusted domain. When sending any event through sharedEvents, these references should be removed. For mouse events, new MouseEvent instances can be created with only the necessary information carried over from the original.
The following example demonstrates how stage events can be sent through thesharedEvents dispatcher. This particular example only forwards a MOUSE_OUTevent in this manner, though it could be done for any number of event types. Note how the parent SWF is protected by using a surrogate event.
http://stageowner.example.com/parent.swf:

var combination:String = "1-2-3-4-5"; // secure data

var loader:Loader = new Loader();
var shared:EventDispatcher = loader.contentLoaderInfo.sharedEvents;

var url:String = "http://untrusted.example.com/child.swf";
loader.load(new URLRequest(url));

stage.addEventListener(MouseEvent.MOUSE_OUT, forwardMouseEvent);

function forwardMouseEvent(event:MouseEvent):void {
 // THREAT! This can expose relatedObject which could in 
 // turn expose this SWF's otherwise secure data
 //shared.dispatchEvent(event);
 
 // Safer: create surrogate MouseEvent to block
 // access to relatedObject reference
 var safeEvent:MouseEvent = new MouseEvent(event.type);
 safeEvent.altKey = event.altKey;
 safeEvent.buttonDown = event.buttonDown;
 safeEvent.ctrlKey = event.ctrlKey;
 safeEvent.delta = event.delta;
 safeEvent.localX = event.localX;
 safeEvent.localY = event.localY;
 safeEvent.shiftKey = event.shiftKey;

 shared.dispatchEvent(safeEvent);
}

http://untrusted.example.com/child.swf:

var shared:EventDispatcher;

// see if stage events can be accessed
// if not, listen for them through sharedEvents
if (loaderInfo.parentAllowsChild){
 stage.addEventListener(MouseEvent.MOUSE_OUT, stageMouseOut);
}else{
 shared = loaderInfo.sharedEvents;
 shared.addEventListener(MouseEvent.MOUSE_OUT, stageMouseOut);
}
 
function stageMouseOut(event:MouseEvent):void {
 // -- stage mouse out actions here --

 // if through sharedEvents the parent passed a reference
 // to the original event, it's data would be accessible!
 //trace(Object(event.relatedObject).root.combination); // 1-2-3-4-5
}

Thanks to the safeEvent MouseEvent instance, the reference to therelatedObject in the original MouseEvent is no longer available. In fact each piece of data which is being exposed is clearly defined before the event is dispatched through sharedEvents. You should always make sure events passed through sharedEvents are cleaned in this manner.

Local Security Domains

SWF files run locally from your hard drive also exist within their own security domains. Local security domains are special cases with unique behavior. They are divided into 4 different security sandbox types: local-with-file, local-with-network, local-trusted, and application for AIR (AIR is not covered in detail here). Together with SWFs on the web, you have a total 5 sandbox types. In ActionScript, you can determine the current type throughSecurity.sandboxType.

local-with-file (Security.LOCAL_WITH_FILE)—This file is a local file, has not been trusted by the user, and it is not a SWF file that was published with a networking designation. The file may read from local data sources but may not communicate with the Internet.
local-with-network (Security.LOCAL_WITH_NETWORK)—This SWF file is a local file, has not been trusted by the user, and was published with a networking designation. The SWF file can communicate with the Internet but cannot read from local data sources.
local-trusted (Security.LOCAL_TRUSTED)—This file is a local file and has been trusted by the user, using either the Flash Player Settings Manager or a FlashPlayerTrust configuration file. The file can read from local data sources and communicate with the Internet.
application (Security.APPLICATION)—This file is running in an AIR application, and it was installed with the package (AIR file) for that application. By default, files in the AIR application sandbox can cross-script any file from any domain (although files outside the AIR application sandbox may not be permitted to cross-script the AIR file). By default, files in the AIR application sandbox can load content and data from any domain.
remote (Security.REMOTE)—This file is from an Internet URL and operates under domain-based sandbox rules.

Local files have strict rules around security because they have access to potentially sensitive material on a user's hard drive. If given the opportunity, a malicious SWF could read data from your computer and post it to an untrusted server on the web. To prevent that, an untrusted local SWF is only allowed to access one or the other, the web (local-with-network) or the local file system (local-with-file), not both. Additionally, local SWFs of different types of these sandboxes cannot be loaded into the same instance of Flash Player in fear that they would work together to access both the file system and the web passing data back and forth between them. For example loading a local-with-network SWF in a local-with-file SWF is prohibited.
Because there aren't exactly any domain names in the land of the local file system, local files determine their sandbox type through a different method. For local-with-file and local-with-network, this is handled through a flag saved in the published SWF. This flag specifies one or the other, a with-file or with-network sandbox. All compiled SWFs have this flag. If they're ever run on locally (and not trusted), it is used to determine the local sandbox type.
For trusted local files, a similar problem exists since there isn't exactly a root domain from which a cross-domain policy file can be served. Instead local files are trusted through a different process; two, in fact. The first is through the onlineGlobal Security Settings panel of the Flash Player Settings Manager. Using a drop-down, you can add file system locations that give local SWFs in that location trust.

Flash Player Settings Manager

The other way is through configuration files. Unlike the Settings Manager, configuration files do not require that you be connected to the internet to use. To specify a SWF or folder of SWFs (including sub folders) place line-separated paths in a .cfg file within Flash Player's #Security\FlashPlayerTrust folder. For Mac and Windows, the locations of this directory are as follows:

Windows 95-XP:
C:\Documents and Settings\[username]\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust

Windows Vista-7:
C:\Users\[username]\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust

Mac OS X:
/Users/[username]/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust

Where [username] is replaced with your current computer user's name.
Both approaches save trust information to your hard drive (the Global Security Settings panel as well, using a special file in a Flash Player-specific directory). These locations act as forms of cross-domain policy files for your local machine. When read by Flash Player, and trust is given to a SWF, the local trust flag in the SWF is overridden and the SWF is given local trust, allowing it to access content on both the web and the local file system.

Local security domains

One caveat of local trust is that you still cannot import content from a remote sandbox with that of a local sandbox, even if the local sandbox is local-trusted. Though a local SWF may be trusted, Flash does not allow what could be arbitrary content from the web to be elevated to the same levels of local trust by bringing it into a local trusted sandbox.
Most player content is designed for the web so the peculiarities of local sandboxes are not usually necessary to fully understand. One exception might be during development and testing. Flash Pro, for example, will place a SWF in a local-trusted sandbox when you test a SWF movie. This can lead to results that differ from the actual, deployed version of the SWF since trusted SWFs are allowed to do much more. For example you might be able to load content from web sites that do not use cross-domain policy files when testing but find that it doesn't work once you place your SWF on the web. Always keep this in mind when testing; what you see may not always be what you get (in the end).
You can find more information about security in general in the Security section of the Flash Player Developer Center (adobe.com).

Application Domains

As seen with security domains, class definitions can be isolated from one another when SWFs are in different security sandboxes, each having their own complete set of definitions to work with. This separation of class definitions (and similar definitions like functions, interfaces, and namespaces) is managed by a subdomain of security domains known as application domains. Every application domain is contained within one, and only one, security domain, though a single security domain can contain any number of application domains.

Application domains exist inside security domains

While security domains sandbox for security, application domains sandbox for definition separation. Specifically, they decide how definition conflicts are resolved and what SWF code have inherent access to what definitions.
Application domains work together in a linked hierarchy making them more complex than security domains which are each isolated and individualized. These hierarchies mirror the display list in Flash. Each application domain can contain any number of child application domains while each child maintains only one parent. Child domains inherit definitions in its parent as well as all of the ancestors of that parent just like position or scale is inherited by child display objects.
At the root of this hierarchy is the system domain, the application domain that contains the native definitions of the Flash Player API. These include definitions like Array, XML, and flash.display.Sprite - anything native to Flash Player. System domains have a one to one relationship with security domains; every security domain contains a single system domain that is created for it when the security domain is first created.
When a new SWF is placed into its respective security domain as it initializes an instance of Flash Player, an application domain is created to contain the ActionScript definitions that were compiled with it. This application domain is then made a child of the system domain in that security domain. As a child domain of the system domain, the native Flash Player definitions are inherently made available to the definitions of that application domain through inheritance.

New SWF domain loaded into and inherits from system domain

More on inheritance is covered in the Application Domain Inheritance section.

Application Domain Placement

The initial SWF instantiating Flash Player always has its definitions loaded into an application domain that is a direct child of the system domain. When that, or some other preexisting SWF (parent) loads another SWF, it has control over where the definitions of the new SWF is placed. There are 4 primary options on where the child SWF's definitions are to placed:

A new child application domain of the parent SWF's application domain (default)
Merged in with the same application domain of the parent SWF
A new child application domain of the system domain in the parent SWF's security domain
A new child application domain of the system domain in a different security domain

All but the very last of the variations each require that the child SWF be loaded into the same security domain as the parent. The fourth and final variation is the only option for SWFs loaded into separate security domains.

Application domain placement options when loading child SWFs

Not mentioned is the option of loading definitions directly into or in a new child domain of any other application domain that was already created for a different, previously loaded SWF. Working with these domains requires more complex ApplicationDomain instance management, usually requiring you to working up an application domain hierarchy using ApplicationDomain.parentDomain - a reference which, as a helpful tip, you may find behaves differently depending on which security sandbox you're testing with (local vs. network). This use case is extremely uncommon so not covered in any more detail here.
The placement of application domains is defined by the applicationDomainproperty of LoaderContext. This property takes an ApplicationDomain instance which can be obtained through ApplicationDomain.currentDomain (much like security domains with SecurityDomain.currentDomain), or by creating a new instance through the use of the new keyword. When creating new instances, a parent domain is passed into the ApplicationDomain constructor to indicate where in the hierarchy the application domain is to exist. Passing no parent implies the system domain will become the parent.

// an application domain that results in definitions that are
// "Merged in with the same application domain of 
// the parent SWF"
var current:ApplicationDomain = ApplicationDomain.currentDomain;

// an application domain that results in definitions being
// added to "A new child application domain of the parent
// SWF's application domain"
var currentChild:ApplicationDomain = new ApplicationDomain(current);

// an application domain that results in definitions being
// added to "A new child application domain of the system
// domain in the parent SWF's security domain"
var systemChild:ApplicationDomain = new ApplicationDomain();

The following example defines a new application domain for a child SWF's definitions that is a child of the parent SWF's application domain. A LoaderContext instance references the ApplictionDomain instance and is passed to the Loader.load call. This is the same behavior that would occur if a LoaderContext was not used at all.

var context:LoaderContext = new LoaderContext();
// load child application domain as a child
// of this application domain 
var current:ApplicationDomain = ApplicationDomain.currentDomain;
context.applicationDomain = new ApplicationDomain(current);

var loader:Loader = new Loader();
var url:String = "child.swf";
loader.load(new URLRequest(url), context);

Incidentally, ApplicationDomain instances cannot be directly compared to one another. Each instance is a unique reference that internally stores a map of its placement in the hierarchy that is not directly exposed to ActionScript.

var current1:ApplicationDomain = ApplicationDomain.currentDomain;
var current2:ApplicationDomain = ApplicationDomain.currentDomain;
trace(current1 == current2); // false

Also, you should not try get a direct reference to the system domain through theparentDomain property. If you need an ApplicationDomain instance to represent the system domain, always use new ApplicationDomain().

Application Domain Inheritance

The inheritance of definitions through application domains is not entirely unlike class inheritance. In both cases definitions in parents are made available to their children while child definitions are not directly exposed to the parents.
Application domain inheritance, however, differs in that child domains aren't given the option to override parent definitions with their own. If a child domain contains a certain definition with the same fully qualified name (name including its package path) as a definition in one of it's ancestor domains, the parent domains's definition will be referenced instead of the child's.

Child application domains use their parent domain definitions over their own

The reasoning behind this can be summarized by the following: you cannot change a class definition out from under an existing class instance. If an instance is created from one version of a class definition and another variation of that definition is then loaded into the player, the class instance would become corrupt with a definition conflicting with that from which it was originally made. Flash player protects definitions by preventing new versions of a definition from ever replacing an existing one.
One of the implications of this behavior is that you're not ever allowed to override native definitions in the ActionScript API with your own. Since a SWF's application domain is always an ancestor of the system domain - where these definitions are defined- there's never an opportunity for a SWF to be able to provide a natively-named definition that does not yet already exist. If a SWF is compiled with such a definition, it will be ignored, overridden by the version in the system domain.
When merging definitions into an existing application domain, the same rules for inheritance apply, even though no inheritance is actually taking place. New application domain definitions are only merged into the existing application domain if they do not conflict with pre-existing definitions that already exist there.

Definitions added to an existing application domain will not replace existing definitions

One minor difference with the dropped definitions in this case is that, unlike with child application domains, these definitions become completely inaccessible. Child domain definitions, even if being overridden by the parent domain can still be accessed from the application domain directly through getDefinition which is covered in the Getting Definitions Dynamically section.
Definitions loaded into an application domain are persistent within that domain, existing as long as the application domain exists. New application domains that are created to hold a loaded SWFs definitions are removed from memory when that SWF is unloaded. If that SWFs definitions were added to another, preexisting domain, they would exist in memory as long as that domain exists, which would be determined by whatever SWF it was created for. If consistently loading new SWF definitions into an existing domain, such as the domain of the first SWF, it could lead to an increase of memory use as definitions continue to add up there. This would be undesirable for something like ad rotation where any number of child SWFs (ads) could be loaded in, each adding their definitions to the same application domain.
Additionally, since definitions loaded in this manner do not unload with the child SWF, reloading that a second time SWF will reuse the original definitions loaded into the application domain from the first time the SWF was loaded. Generally this would not be a problem since the definitions are the same, but it would mean that the static state of classes would not reset; static variables that were changed the first time the SWF was loaded would still retain their changed values rather than resetting to their defaults when the SWF was reloaded.
Different circumstances require different approaches.

Child Domains: Definition Versioning

Inheritance through child domains make it easy for parent SWFs to share their definitions with child SWFs. And because definitions in child domains are overridden by parent definitions of the same name, the parent application domain gets to control what versions of those definitions are used by its children.

Child application domain inherits from its parent

Consider a SWF-based web site that loads separate SWFs to represent the content of different pages within the site. The main SWF simply being a shell for loading these pages. Each of the page SWFs have similar behavior based on a common code library. A shared class may be, for example, a PageTitle class which defines a display object used to display a page's title text.
Now consider a second SWF on that same domain that serves a slightly different purpose but uses the same child pages for some of its content. This particular SWF, however, requires that the titles in child pages not use selectable text (the current behavior being selectable). To do this, at least within the scope of this example, the PageTitle class would need to be updated to make its TextField have a selectable value of false. The problem is, the original SWF needs to retain the old behavior of having selectable title text.
To solve this problem, each page could be duplicated and recompiled with the changes. But this would require additional disk space for the copies, increase bandwidth requirements, and has a negative impact on site maintainability. A better solution would be to include a revised version of the PageTitle class in the contents of the second SWF. Then, as child pages are loaded into child application domains, they'll inherit and use that version of the class over their own.
Original PageTitle class used by all child pages:

package {
 import flash.display.Sprite;
 import flash.text.TextField;

 public class PageTitle extends Sprite {

  private var title:TextField;

  public function PageTitle(titleText:String){
   title = new TextField();
   title.text = titleText;
   addChild(title);
  }
 }
}

The version of the PageTitle class compiled into the second SWF shell:

package {
 import flash.display.Sprite;
 import flash.text.TextField;

 public class PageTitle extends Sprite {

  private var title:TextField;

  public function PageTitle(titleText:String){
   title = new TextField();
   title.text = titleText;
   title.selectable = false; // changed
   addChild(title);
  }
 }
}

When the new shell is compiled, it's compiled with the changed version of the class, loading all of the child pages into child application domains.

PageTitle; // include a reference of edited 
// class to have it compiled in the SWF even
// though the SWF is not using it directly

// load child pages into child application domains
// loaded SWFs will use the version of PageTitle
// in this SWF rather than their own
function addChildPage(url:String):void {
 var context:LoaderContext = new LoaderContext();
 var current:ApplicationDomain = ApplicationDomain.currentDomain;
 context.applicationDomain = new ApplicationDomain(current);
 
 var loader:Loader = new Loader();
 addChild(loader);
 loader.load(new URLRequest(url), context);
}

This approach allows class definitions to be changed in loaded content without recompiling or changing their default behavior. Changes are simply the result of a parent application domain replacing definitions in the child with its own revised versions.
Note that the above example could have also omitted the use of the LoaderContext for the same effect.
Even if child SWFs don't have to serve multiple purposes, it might come down to it just being easier to update definitions in the loader rather than all the children. In fact, child SWFs could be compiled without these classes at all, relying entirely on the versions supplied by the parent. More information on how that works is seen in the Same Domain: Runtime Shared Libraries section.

Separate Domains: Preventing Conflicts

Sometimes you'll have projects which require loading SWF content that shouldn't be affected by parent application domain inheritance. You may not want the SWF to inherit parent definitions or maybe not even know what definitions it uses at all. Whatever the case, it would be best to avoid any kind of definition sharing between the main SWF and the loaded content. This is when you load child SWF definitions into a new application domain that is a child of the system domain.

Child application domain made a separate child of system domain

Because no inheritance exists between the parent and child SWFs, both can have definitions of the same name - which may or may not be the same definitions - that can co-exist within their own sandboxes without having to worry about creating a naming conflict.
Here's a scenario: Let's say you have training application that loads training modules through external SWFs. Hundreds if not thousands of these modules exist, having been developed by many different people throughout many years that this application has been in use. As the modules were being developed, the codebase they've been using has evolved. This creates a discrepancy between the versions of the codebase between different modules, and even the training application itself (which also uses the same codebase). Because the training application and the different modules use and rely on different versions of the same codebase, the training application will need to be sure that its version of the codebase is not used by the modules since its version could be incompatible with their design. To do this, the training application has to load modules in a new application domain that is a direct child of the system domain rather than in application domains that are children of its own.
trainingapplication.swf:

var moduleLoader:Loader = new Loader();
addChild(moduleLoader);

// load modules into application domains that
// are direct children of the system domain
// so that this application domain does not
// share definitions with them
function loadModule(url:String):void {
 var context:LoaderContext = new LoaderContext();
 context.applicationDomain = new ApplicationDomain();
 
 moduleLoader.load(new URLRequest(url), context);
}

Unfortunately, definition separation in this case is not absolute. All content within the same security domain shares the same system application domain. Any changes made to definitions there will be reflected in all other application domains in that security domain. So even though a child SWF is loaded into a separated application domain that is a direct child of the system domain, changes to that system domain from the parent SWF would still be reflected in the child.
This is evident with the XML.prettyIndent example. One SWF, no matter where it is in the application domain hierarchy, if in the same security domain, will affect all other SWFs with changes made to definitions in the shared system domain.
parent.swf:

trace(XML.prettyIndent); // 2
XML.prettyIndent = 5;
trace(XML.prettyIndent); // 5

var loader:Loader = new Loader();

var context:LoaderContext = new LoaderContext();
// separate application domain from this one
context.applicationDomain = new ApplicationDomain();

var url:String = "child.swf";
loader.load(new URLRequest(url), context);

child.swf:

trace(XML.prettyIndent); // 5

As a best practice, changes to definitions like this should be done on a temporary basis, returning values to their defaults after use.

var originalPrettyIndent:int = XML.prettyIndent;
XML.prettyIndent = 5;
trace(myXML.toXMLString());
XML.prettyIndent = originalPrettyIndent;

Also, as a precaution, you may want to make sure such values are what you expect them to be in case someone else changed them out from under you.

Same Domain: Runtime Shared Libraries

Probably the most powerful usage of application domains involves adding new definitions into a pre-existing application domain. Whereas child domains only allows definitions to be shared from a parent to a child, merging definitions in to the same application domain provides a single domain from which all definitions can be shared by every SWF using it, both parent and child.

Parent application domain includes child definitions

Runtime shared libraries (RSLs) use application domains in this manner. RSLs are code libraries that exist as separate SWFs that can be loaded in at runtime. They allow one or more SWFs share a single codebase without each SWF having to embed that same code into their SWF file, thus reducing redundancy, file size, and making code more maintainable. RSL definitions are loaded into the application domain of the loader, thereby allowing that application to access the new definitions.
A couple prerequisites need to be met for RSLs to function properly. First, the ActionScript compiler needs to know that certain definitions are going to be used by a SWF but should not be compiled in with the SWF when published.
The compiler does this now with native Flash Player definitions. Though a SWF will use native player definitions in its code (Array, XML, Sprite, etc.), those definitions only exist within the Flash Player executable itself and should not, nor cannot be compiled into the SWF when its published. The compiler uses a special SWC (a pre-compiled SWF code library) called playerglobal.swc to recognize these native definitions. It contains the interface for these definitions - their names and type information - allowing the compiler to compile code using them, but at the same time the compiler is smart enough to know that they are not included with the final SWF.
The compiler can reference other SWC libraries that can behave like playerglobal.swc. Definitions in these libraries can be referenced by code in your SWF, but not compiled into the SWF when published. These libraries are linked as "External" libraries - external in that they are externally loaded rather than be internal to the SWF.
I will not cover how exactly this is setup as it changes depending on your authoring tool. You should be able to reference your tool's documentation to learn how to set this up for your particular environment.
Though SWCs are used for compilation, RSLs are, themselves, SWFs, just like any other loaded Flash content. When compiling library code, both a SWF and a SWC should be made - the SWF for loading at runtime and the SWC to reference in your external library path.

Shared Library SWCs are used by the compiler; Shared library SWFs are loaded at runtime

The other prerequisite deals with code execution. Using external libraries, a SWF will be published without definitions that it depends on to function. Should Flash Player attempt to run code that doesn't contain an expected definition, a verify error can occur, (for the most part) breaking your SWF completely.
Flash Player verifies classes when they're first used in code. If certain definitions are not present in the application domain when this verification process occurs, an error is thrown.
There are actually two different kinds of errors that can occur as a result of missing definitions. Verify errors are the worst of the two, representing a catastrophic failure in a class's ability to function. These are a result of a specifictype being used and not being available. However missing definition referencescan also create a failure that results in reference errors. These errors only interrupt the normal flow of code execution within code executing within an already verified class.

var instance:DoesNotExist;
// VerifyError: Error #1014: Class DoesNotExist could not be found.
// Occurs as the class containing this definition is verified

var instance:Object = new DoesNotExist();
// ReferenceError: Error #1065: Variable DoesNotExist is not defined.
// Occurs when this line of code executes

The main difference is that verify errors relate to a class's definition while reference errors are specific to code execution. For any code within a class to execute, verification would have needed to pass. Since the reference error example above uses a type of Object for the instance variable, verification was able to succeed and code was able to execute (only to then fail with a reference error).

Note: Strict ModeExternal libraries are one way you can compile SWFs that use definitions that aren't compiled into the SWF. Another approach is to turn strict mode off. This greatly reduces the compiler's strictness with how variable values are used. For class usage, you can reference classes that do not exist without invoking a compiler error. You can't use them as types - something which would cause a verify error at runtime - but you can reference classes by name as seen with the reference error example above. This approach is not recommended because of possible errors that might slip through undetected.

For SWFs loading RSLs, this means classes that use or reference definitions in an RSL should be avoided until the dependent RSLs load. A preloader at the start of an application can facilitate this, loading RSLs before main application code - which uses RSL code - runs.
The example below includes a SWF that loads in a RSL containing a Doughnut class. Though this class is used directly in the SWF's own, internal code, it was not compiled into the SWF because it was referenced through a SWC defined as an external library. The RSL SWF is loaded before the Doughnut class is used so verification does not fail.
Doughnut.as (compiled into doughnutLibrary.swc anddoughnutLibrary.swf):

package {
 import flash.display.Sprite;
 
 public class Doughnut extends Sprite {
  public function Doughnut(){

   // draw a doughnut shape
   graphics.beginFill(0xFF99AA);
   graphics.drawCircle(0, 0, 50);
   graphics.drawCircle(0, 0, 25);
  }
 }
}

ShapesMain.as (where primary Shapes.swf content is defined):

package {
 import flash.display.Sprite;
 
 public class ShapesMain extends Sprite {
  public function ShapesMain(){

   // The Doughnut class is accessible
   // through the linked doughnutLibrary.swc
   // though not compiled into Shapes.swf
   // because its linked as an external library
   var donut:Doughnut = new Doughnut();
   donut.x = 100;
   donut.y = 100;
   addChild(donut);
  }
 }
}

Shapes.swf (RSL loader):

var rslLoader:Loader = new Loader();
rslLoader.contentLoaderInfo.addEventListener(Event.INIT, rslInit);

// load definitions in the RSL SWF into the
// current application domain
var context:LoaderContext = new LoaderContext();
context.applicationDomain = ApplicationDomain.currentDomain;

var url:String = "doughnutLibrary.swf";
rslLoader.load(new URLRequest(url), context);

function rslInit(event:Event):void {

 // only when the RSL definitions have been imported
 // into the application domain do we allow use of and
 // thereby verification of the ShapesMain class which
 // makes use of the Doughnut definition in the RSL
 addChild(new ShapesMain());
}

The Shapes SWF here represents the main SWF application. It's functional content is defined in a separate class called ShapesMain. This class isn't instantiated until the RSL loader has been able to import the RSL definitions (Doughnut) into the application domain. Without the RSL definitions, a verify error would have occurred as soon as the ShapesMain class was verified and the Doughnut class was found missing from the application domain.

Note: RSLs with FlexThe Flex framework has its own implementation of handling RSLs. The approaches explained here are very low level and generally should not be used when developing a Flex application. For more information around RSL usage in Flex, see Flex Runtime Shared Libraries (Flex 4).

Getting Definitions Dynamically

Definitions not included in a application domain, or inherited by a parent domain, can be obtained from other domains dynamically throughApplicationDomain.getDefinition. This method returns a reference to a definition that exists in an application domain or any of its parents. CallinggetDefinition with the current application domain mirrors the global functiongetDefinitionByName.
Outside of ApplicationDomain.currentDomain, you can also get a reference to an ApplicationDomain instance - one specific to a SWF - usingLoaderInfo.applicationDomain. This is what would be used to find ApplicationDomain references for other SWFs or application domains as the following example demonstrates with a com.example.Box class that was compiled in the SWF loaded into the loader Loader instance.

try {
 var domain:ApplicationDomain = loader.contentLoaderInfo.applicationDomain;
 var boxClass:Class = domain.getDefinition("com.example.Box") as Class;
 var boxInstance:Object = new boxClass();
}catch(err:Error){
 trace(err.message);
}

There are a couple of points of interest in this code snippet. First, notice the the return value of getDefinition was cast to a the type Class with as Class. This is needed because getDefinition returns a value of the type Object since it's capable of returning any kind of definition (functions, namespaces, interfaces) rather than just classes. Also, the whole operation is wrapped in a try-catch. This is needed because failure to find a definition through getDefinition throws an error. Alternatively, you could also check this usingApplicationDomain.hasDefinition which would let you know ifgetDefinition would be able to successfully find the desired definition or not.
Definitions acquired dynamically that are not a part of (or inherited by) the current application domain cannot be used as variable types. As seen with RSLs, if a type is used for a class but not contained within the application domain when the class is verified, an error will be thrown. In the above example you can see theboxInstance variable is typed as Object instead of Box because the Box class is not a known definition in the application domain.

Same-definition Collisions

Sometimes, definitions may get crossed and you may have a definition in one application domain that matches a definition in another, unrelated application domain and an assignment is made across the two types. When this happens, you'll get an error that resembles the following:

TypeError: Error #1034: Type Coercion failed: cannot convert 
 com.example::MyClass@51e1101 to com.example.MyClass.

The separation of the definitions can be seen with the identifier following the @ symbol in the class name indicating that the definition exists in a different memory space. Even though the definitions may (or may not) be exactly the same in code, they have been defined in Flash Player by two separated application (or security) domains meaning two instances of the class exist.
Only native Flash Player definitions can bridge this gap allowing a type likeObject to work for both cases, even going across security domains. In fact, you'll probably use Object to type instances whose type is not a part of the current application domain most of the time.
Though using a more generic type like Object will help solve collision errors, a different use of application domain placement would actually allow the definitions to match.

Conclusion

This tutorial has covered a lot of information. The first half dove deep into security domains and how they affect content on different source domains. Security domain sandboxing by Flash Player protects the user and their data, and it's important that developers of Flash content both respect and understand the restrictions imposed by Flash Player in that space

=================================

저작자표시

'ADOBE > ActionScript' 카테고리의 다른 글

ActionScript 개발 결제 air그리고 IOS, android 결제 관련 (0)	2020.09.22
[ANE] Free AIR Native Extensions Collection (0)	2020.09.22
[AS] AS3: Inline graphics using Text Layout Framework 액션스크립트 텍스트필드에 원하는 대로 한줄 부분의 글중간에 이미지 넣기 관련 (0)	2020.09.22
[AS] 액션스크립트 텍스트 필드에 이미지 사용 (0)	2020.09.22
[AS] swc 안의 class를 getDefinition, getDefinitionByName 으로 불러내기 관련 (0)	2020.09.22

알레폰드의 테크 이모저모

고정 헤더 영역

메뉴 레이어

메뉴 리스트

검색 레이어

검색 영역

상세 컨텐츠

본문 제목

본문

Security Domains, Application Domains, and More in ActionScript 3.0

Introduction

Sandboxing

Security Domains

Trust

Non-executable Trust

Non-executable Content Without Trust

SWF Communication Without Trust

Merging Security Domains

Stage Owner and Access

Local Security Domains

Application Domains

Application Domain Placement

Application Domain Inheritance

Child Domains: Definition Versioning

Separate Domains: Preventing Conflicts

Same Domain: Runtime Shared Libraries

Getting Definitions Dynamically

Same-definition Collisions

Conclusion

'ADOBE > ActionScript' 카테고리의 다른 글

관련글 더보기

댓글 영역

추가 정보

인기글

최신글

티스토리툴바