도메인이 서로 다른 곳에서 swf 간 통신이나 접근을 하기위해서는 해당 도메인을 접근가능하도록 메서드를 통해 도메인을 사전에 등록하는 방법과 외부 정책 파일을 로드해서 사용하는 방법이 있는데 플래시 8에서는 접근을 허용할 도메인의 최상위 디렉토리(root)에 정책 파일이 있어야 했지만 이제는 정책 파일을 사용자가 원하는 위치에 올려 놓고 로드해서 사용할 수 있습니다.
flash.system.Security.loadPolicyFile()
메서드를 통해 특정 위치의 정책 파일을 로드할 수 있습니다. 정책 파일은 crossdomain.xml을 의미합니다.
The problem is that it works fine for some persons (like me) but for some other persons it doesn't work. I log the problem and I found that they have a SecurityError :
I don't understand why It works for some and not for the others. Maybe a strange coincidence : it works for the people who are in france (4 testers) and not outside (a test in Swiss and one in Belgium).
플래시로 PC에 저장되어 있는 파일을 업로드하는 것은 매우 쉽습니다. 구글에서 플래시 업로드로 검색해보면 여러가지 공개된 소스가 보입니다. 그 만큼 간단하다는 얘기!
플래시 ActionScript에 FileReference 클래스가 있습니다. 이 것은 사용자에게 파일을 선택할 수 있는 대화상자를 출력하고 사용자가 선택한 파일을 서버로 업로드하는 기능을 제공합니다. 업로드는 HTTP 프로토콜로 이루어 집니다. 구체적인 업로드 내부 메커니즘은 HTTP 업로드에 대해서 라는 글을 참고하세요.
그렇담 이번에는 플래시 내부에서 가공된 데이터를 어떻게 업로드할 수 있을까를 생각해 봅시다. 예를 들어 FileReference로 사용자가 선택한 이미지 파일을 썸네일로 만들어 서버로 전송해야 합니다. 사용자가 선택한 원본 이미지 데이터를 FileReference에 있지만 새롭게 생성한 썸네일 데이터는 메모리에 있습니다. 이를 FileReference에 넣을 방법은 없습니다. 아래 코드는 원본 이미지 데이터에서 썸네일 비트맵을 만든 후 해당 비트맵을 JPEG으로 압축하는 예입니다.
var bmd:BitmapData = currentEditor.baseImage.getThumbnailData(200, 100);
var encoder:JPEGEncoder = new JPEGEncoder(90);
var thumbData:ByteArray = encoder.encode(bmd);
만들어진 thumbData를 서버로 어떻게 전송할 수 있을까요? 해답은 URLRequest와 URLLoader를 사용하는 것입니다. HTTP 업로드에 대해서에서 설명한 multipart/form-data 형식의 POST 데이터를 생성해 HTTP 요청을 직접 구성한 후 URLLoader로 HTTP 통신을 진행합니다. UploadPostUtil은 MIME 형식의 multipart/form-data를 만드는 클래스로 기본 ActionScript 클래스는 아닙니다(제가 개인적으로 구현해 사용하는 클래스입니다. 따라서 flex 도움말에는 없습니다).
var uploadPost:UploadPostUtil = new UploadPostUtil(); uploadPost.addFile("file1", "thumb.jpg", pngData);
var urlLoader:URLLoader = new URLLoader(); urlLoader.dataFormat = URLLoaderDataFormat.BINARY; urlLoader.addEventListener(Event.COMPLETE, onUploadComplete); urlLoader.addEventListener(IOErrorEvent.IO_ERROR, onUploadError); urlLoader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onUploadError); urlLoader.load(urlRequest);
위 코드를 실행하면 multipart/form-data로 데이터를 서버로 전송하고 서버측은 각 개발 환경에 맞는 HTTP 업로드 수신 모듈을 가동하면 업로드 된 데이터를 처리할 수 있게 됩니다. 여기까지는 그나마 쉽습니다.
아마 이 방식이 플래시 데이터 업로드의 정석일 겁니다. 하지만 치명적인 문제가 있습니다. 썸네일과 같이 적은 량의 데이터를 보내는데는 적절하지만 수십 MB를 전송할 경우 전송 시작 부터 완료까지 플래시가 먹통이 됩니다.
이유는 URLLoader에 있습니다. 클래스 이름에서 보듯이 서버에 있는 데이터를 HTTP로 로딩하는 게 주요 기능입니다. 반대로 클라이언트 데이터를 서버로 전송하는 것은 주요 기능이 아닙니다. 위 코드에서 보듯 POST 형식으로 직접 만들어 전송을 해야하는 번거로움이 있습니다. 게다가 로딩에 초점에 맞추어져 있다보니 로딩에만 progress 이벤트를 받을 수 있습니다. HTTP 요청이 전송되는 업로드에는 progress 이벤트가 없습니다(FileReference는 있습니다). 대략 낭패입니다. 100MB를 보내는 과정을 출력하지도 못하면서 사용자에게 계속 기다려라 라고 해야 하니 UI과 완전 꽝입니다.
여기에서 방향을 전환해 TABSFileup4를 개발할 때 사용했던 소켓 수준의 통신으로 HTTP 업로드를 구현한다면 프로그레스 출력 및 업로드 도중 취소 등 여러가지를 자유롭게 구현할 수 있으리라 생각해 개발을 진행했었습니다.
그러나 웬걸!!!!
socket.connect(host, 80)을 호출하니 플래시 플레이어가 SECURITY_ERROR(#2048) 오류를 띄웁니다. 공포의 샌드박스 오류가 뜹니다. FLEX 업로드에 따른 샌드박스 보안 오류에서 설명한 multipart/form-data 검출에 의한 보안 오류가 아닌 80번 포트로 직접 연결을 제한하는 보안 오류입니다. 플래시를 사용해 사용자 몰래 소켓 통신을 하지 마라 라는 의미입니다.
Setting up a socket policy file server 라는 어도비 기술 문서를 보면 소켓을 통한 TCP/IP 연결시 여러 조건에 의해 3가지 순서로 보안 검사를 한다라고 명시되어 있습니다. 복잡하니까 다 생략하고 소켓 통신을 위한 핵심 보안에 대해서만 설명하고자 합니다.
socket.connect(host, 80)을 호출하면 80 포트로 연결하기 전에 host의 843 포트로 연결합니다. 이 포트에는 socket master policy file을 반환하는 서버 애플리케이션이 리슨하고 있어야 합니다. 프로토콜은 다음과 같이 매우 간단합니다.
정책 파일 서버는 843 포트를 리슨하고 있다가 <policy-file-request/> 요청이 들어오면 정책 파일(XML)을 전송하고 소켓을 닫으면 됩니다.
SWF 파일이 소켓으로 연결하고자 하는 곳에 정책 파일 서버가 존재해야 하고, 정책이 tabslab.com 도메인에서 배포된 SWF에 대해서 80 포트만 접속을 허락하니 그 외의 모든 연결은 보안상 오류로 취급됩니다. 따라서 정책 파일 서버가 없거나 정책 파일 서버가 허락하지 않는 from 도메인과 포트로의 접근은 플레시 플레이어 자체가 제한해 버립니다. 아무곳으로의 통신을 막아 보안성을 높이게 되는거죠.
원래의 목적인 소켓 기반 HTTP 업로드를 위해 단계 별로 설명하자면...
(1) 도메인 내에서 업로드를 받는 서버의 방화벽에서 843 포트를 개방합니다.
(2) 정책 파일 서버를 설치한 후 가동시킵니다. Telnet으로 연결 후 <policy-file-request/>를 전송해 올바른 응답을 하는지 테스트합니다.
(3) socket.connect(host, 80)로 연결 테스트합니다.
연결에 성공하면 소켓 기반으로 HTTP 업로드 요청을 생성해서 전송합니다. Socket 클래스는 progress 이벤트를 제공하고, close 메서드를 사용해 연결을 끊는 등 보다 세부적인 제어가 가능하므로 보다 향상된 UI를 구성할 수 있습니다.
해당 주소 중 유념히 살펴봐야 할 부분이 http 와 https 프로토콜이다. 같은 서버있지만 서로 다른 샌드박스로 인식하고 있다는 것이다. 흔히 개발자들은 '사용하고자 하는 데이터가 다른 서버에 존재할 때만 보안문제가 발생한다'라고 알고있다. 그러나 플래시에서는 '프로토콜이 다를 때도 보안문제가 발생할 수 있다'라는 걸 알 수 있다.
해당 도메인들을 허가해주는 Cross-Script 핵심문구. 외부서버에 있는 SWF파일 로드 시 사용.
- allowInsecureDomain( ..domains ): void
해당 도메이들을 security=false해서 https방식으로 보안.
- loadPolicyFile( url: String ): void
도메인 허가를 외부 보안 정책 xml로부터 허가. 외부서버에 있는 데이터파일( xml, text ) 로드 시 사용.
- showSettings( panel:String = "default" ): void
보안 정책 관련 셋팅 화면 표시.
HTML에서 원격 보안
<object>
<param name="allowNetworking" value="none" />
<embed>
//생략
</embed>
</object>
allowNetworking 파라메타에 추가할 수 있는 값.
- all( default ) network 관련 명령어 모두 사용 가능.
- internal 다른 사이트로 이동하는 브라우저관련 명령어만 사용 불가.
- none 모든 network 기능 불가. SWF-SWF간 통신 불가.
Loader 클래스와 LoaderContext 클래스
Loader 클래스는 이미지 파일과 swf 파일을 로딩한 후, DisplayObjectContainer에 삽입이 가능한 DisplayObject.
LoaderContext 클래스는 Loader 클래스를 사용할 때 보안샌드박스 관련 제어를 하도록 3개의 속성을 지원.
- checkPolicyFile: Boolean = false
기본 'false' 설정.
로딩전 cross-domain.xml(보안 정책 파일) 보안 정책 파일 체크 여부.
외부 서버에 있는 이미지 파일을 로드하기 전에 먼저 보안 정책 파일이 있는지 여부를 먼저 체크 후 이미지 로딩.
보안 정책 파일이 없거나, 설정이 false인 경우 외부 서버에 있는 이미지 로드 시 보안에러 발생.
- applicatioinDomain : ApplicationDomain = null
SWF파일을 다운로드하는 경우에만 유효한 속성.
응용 프로그램 도메인은 보안을 위한 것이 아니며 서로 관련된 ActionScript 코드 단위를 관리하기 위한 것입니다.
예제)
kor 과 en 이라는 폴더에 같은 파일명( Sample.as )의 클래스가 있다고 했을 때 메인에서 이 두파일을 로드하게 되면 서로 같은 클래스명을 갖고 있기 때문에 마지막로드된 클래스로 속성 및 메서드가 대체되는 문제가 발생합니다.
이 때 LoaderContext.applicatioinDomain = new ApplicationDomain(); 새로운 도메인을 설정해주어 여러 클래스를 구분해주면 해결됩니다.
- securityDomain: SecurityDomain = null
SWF파일을 다운로드하는 경우에만 유효한 속성.
보안 도메인을 선택하는 이유
첫째 - 로드하는 SWF 파일이 같을 경우.
자신의 도메인에서 SWF 파일을 로드하면 파일이 항상 자신의 보안 도메인에 배치됩니다.
둘째 - 다른 도메인(다른 서버)일 수 있는 SWF 파일을 로드하는 경우에만 의미가 있음.
다른 도메인의 SWF 파일을 로드할 때는 두 가지 옵션이 있습니다.
로드되는 SWF 파일이 로드하는 SWF 파일의 보안 도메인과 다른 "고유의" 보안 도메인에 배치되도록 할 수 있으며,
이는 기본 옵션입니다.
다른 옵션은 myLoaderContext.securityDomain을 SecurityDomain.currentDomain으로 설정하여 로드되는 SWF 파일이 로드하는 SWF 파일과 같은 보안 도메인에 배치되도록 지정하는 것입니다. 이를 '가져오기 로딩'이라고 하며, 보안을 위해 로드되는 SWF 파일을 자신의 서버로 복사한 다음 로드하는 것과 같습니다. 가져오기 로딩에 성공하려면 로드되는 SWF 파일의 서버에 로드하는 SWF 파일의 도메인을 신뢰하는 정책 파일이 있어야 합니다.
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();
[SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048: 보안 샌드박스 문제가 발생했습니다. file:///C|/Documents%20and%20Settings/Administrator/바탕%20화면/test.swf은(는) http://www.google.co.kr에서 데이터를 로드할 수 없습니다."]
플래시의 보안정책은 swf 가 배치된 위치에 따라서 달라집니다. 파일이 로컬에 배치된 경우 local-with-filesystem 샌드박스에 할당되며, 네트워크와는 일체 통신을 할 수 없습니다. 따라서 네트워크와의 통신이 가능한 샌드박스 타입이 할당될 수 있도록 설정을 변경해 주어야 하는데요,
일반적인 테스트 용도로만 사용할 목적이라면 '플래시 플레이어 우클릭 -> 전역 설정 -> 고급 -> 신뢰할 수 있는 위치 설정'에 해당 파일 또는 경로를 포함시켜 네트워킹을 시도할 수 있는 샌드박스 타입으로(local-trusted 샌드박스) 직접 변경할 수 있습니다.
2011/11/02 23:22답글따숩소님이 말씀하신부분은,, 웹페이지에서 플래시부분에서 우클릭을 하면 전역설정 부분이 뜨긴했었는데 그 부분을 말씀하신것 같습니다. 지금은 어떤건 뜨고 어떤건 안뜨더군요,, 플래시 플레이어 업데이트 되면서 바뀐듯,, 아무튼,, 전역설정을 하게되면 콰즈님 말씀대로 샌드박스에 상관없이(말이 맞는지 잘 모르겠네요 ㅎㅎ) 페이지에 접근을 할수 있게 됩니다. 테스트에 있어서 보안에 자유로워 지죠,,,테스트 중일 경우시라면
2011/11/03 16:12답글아 답변감사드려요. (영광까지 ㅎ; 그런데 제가 궁금했던 것은 보안샌드박스를 변경하지 않고도 로드를 할 수 있는 방법 이었어요... 질문내용에 적혀있는 구글의 crossdomain.xml 내용은 모든 사이트에서 로드를 허가한다는 내용이 아닌가요??
2012/02/22 09:42답글엇 플루톤님..감사합니다 ^^ 잘 작성해주신 강좌는 모두 읽었습니다 ^^ 이전에 크게 도움이 되었지요. 알려주신 Air 서버소켓을 이용해서는 이번주 월요일에 해봤습니다. 정상적으로 정책파일 주고 받으며 잘 작동하는데.. 아무래도 환경이 문제인 듯 합니다. 댓글 주셔서 감사합니다!~
Adobe Flash의 소켓 정책(socket flash or flash policy or cross-domain (socket) policy)은 Flash Player 의 소켓 연결과 관련된 보안 정책을 처리하는 방법을 기술한다. 특히 이종 도메인간의 연결은 이 것 없인 불가능하다.
즉 web.upnl.org 에 서비스되고 있는 플래쉬 파일이 app1.upnl.org에 접속하려는 경우 web.upnl.org 가 현재 도메인(source domain)이 되며, 이 서버에서 다운로드 받은 some.swf 파일이 접근하는 (데이터/응용서버) app1.upnl.org 가 remote domain이 된다.
이 때 some.swf 파일을 app1.upnl.org 에 도메인간 정책 파일을 요구하고, 이 파일이
“web.upnl.org”로 부터의 접속을 나의 이런이런 포트로 허용한다
같은 형식인 경우에만 Flash Player가 실제로 접속을 허가한다.
Historical notes
Flash 9의 일정 버젼까지는 http://app1.upnl.org/crossdomain.xml 처럼 루트 디렉토리의 crossdomain.xml 파일로 지정되는 파일에 정의되었다. 그리고 1024번 보다 상위 포트로는 (즉 non-priviliged ports로는) 접속이 가능했었다. 그러나 이게 9.0.124.0 이후로 변경됨 (모든 포트에 정책 파일이 필요)
그리고 현재(Flash 9)엔 IANA와의 협의에 의해 843 번 포트를 사용하기 시작하였다.
실제로 동작할 때의 접속 순서
some.swf 파일이 로드되면, 843 번 포트로 <policy-file-request/>\0 라는 메시지를 보낸다.[2] 이게 실패하거나, 성공했는데도 site-control이 all인 경우, 다음으로 간다.
Security.loadPolicyFile() 명령이 들어있고, 이게 어떤 검사할 위치를 주는 경우 그 파일을 가져온다. 다만 1이 실패한 경우에만임에 주의
접속한 소켓에, 접속한 순간에 <policy-file-request>\0 를 전송하고 응답을 기다린다. 첫 응답은 text/xml 의 정책 파일이어야 함.
Terminology에 따른 설정
일단 3을 막아야 서버는 독립적으로 짤 수 있다. 즉 XML Socket을 일반적인 TCP 소켓처럼 쓰는 걸 짜야했던 내 경우엔 정말 그렇게 해야한다. 물론 XML 기반의 처리라면 그냥 받아서 처리해도 편하겠지만.
같은 식으로 하면 web.upnl.org 에서 다운로드된 some.swf 가 app1.upnl.org 의 4000~4002, 4020~4060에 접속할 수 있게 된다.
저기서 도메인을 앗싸리(…) *.upnl.org 같은 꼴을 할 수도 있지만, 그건 비권고 사항 중 하나. * 도 가능하지만 그건 정말(…). ((사실상 한단계 걸러줄 수 있는걸 뚫어놓은 결과니 + 나중에 처리는 해야겠지만 개발단계라면 모를까 굳이 막을 수 있는걸 안 막을 이유는 없는듯.))
물론 이 policy file이 서비스되어야 하는 위치는 app1.upnl.org 라는 사실엔 두말할 여지가 없는듯… [3]
덤으로 소켓이 HTTPS 일지 여부(SSL사용)도 지정할 수 있지만 내가 신경쓸 범위가 아닌 (개발이 아닌 publish-issue) 거라 그냥 생략.
site-control
site-control 은 플래쉬 정책 파일이 허용되는 위치 — 즉 casecade되어 허용될지/말지 등등 — 에 관한 사항을 설명한다
allowed-access-from
개인적으로 헷갈리는 태그 명인데 -_-; “저기서 언급된 도메인에서 다운로드된 플래쉬 파일을 저 파일이 있는 서버의 특정 포트에 접근하게 해준다” 는 의미다.
즉 저 위에선, web.upnl.org 에서 온 파일이면 to-ports 밑에 언급된 포트로 접근가능하다는 의미. [4]
그림으로 따지면 adobe.com에서 가져온 다음 그림의 프로세스를 따라간다고 생각하면 쉽다.
예를 들어 예전에 포스팅했던 UNIQLO의 광고 같은 경우 전체 데이터를 다 가지고 있는 건 좀 말이 안된다. 네트웍 대역폭을 잡아먹긴 하겠지만, 일종의 플레이어가 다운로드 되고, 그 플레이어가 해당 플래쉬 파일이 있던 서버가 아닌 다른 서버에 접속해서, 스트리밍 동영상을 가져오는게 말이 될 것이다. [↩]
XMLSocket의 관례인지 뒤에 NULL이 붙는다. 위에서 나오는 <policy-file-request/>\0 는 일단 문서에 따르면, 더 늘어나거나 줄지 않는다. 다만 이걸 수정해서 보내게 만들 수도 없다
[↩]
방법이야 위에서 쓴 843 포트에 XMLHTTPRequest를 처리한다거나, 소켓의 첫 응답을 처리한다거나… [↩]
I want to run a JsSocket on my local machine (localhost), i donwload JsSocket fromhttp://code.google.com/p/jssockets/ , i create a sub-folder 'jssockets' under easyphp's 'www' folder, where i unzip the JsSocket package. after i edit the JSSocket.mxml by adding this lines to "connect" function :
i builder JsSocket.mxml by FLex builder 3, after i replace the original JsSockety.swf by the JsSockety.swf spring from the flex builder. on easy php i add alias "http://127.0.0.1/jssockets/" to my jssockets's folder and i create a crossdomain.xml to allow all domain acces
i run my Java Server on the port 10000 and i run on the ie 8 browser the index.html from adressehttp://127.0.0.1/jssockets/ and i try to connect my JsSocket to the host http://127.0.0.1/jssockets/ on the port 10000 but evry what i do i have always this error
XML 파일이나 텍스트 파일과 같은 데이터를 로드할 수 있습니다. URLLoader 및 URLStream 클래스의 load() 메서드는 크로스 도메인 정책 파일 권한으로 제어합니다.
load() 메서드를 사용하여 해당 메서드를 호출하는 SWF 파일의 도메인이 아닌 다른 도메인의 내용을 로드하는 경우, Flash Player는 로드되는 에셋의 서버에서 크로스 도메인 정책 파일을 확인합니다. 크로스 도메인 정책 파일이 있으면 로드하는 SWF 파일의 도메인에 대한 액세스가 허용되고 데이터를 로드할 수 있습니다.
소켓 연결
소켓 및 XML 소켓 연결에 대한 크로스 도메인 액세스는 기본적으로 비활성화됩니다. 또한 1024 미만의 포트에서 SWF 파일과 동일한 도메인에 있는 소켓 연결에 대한 액세스도 기본적으로 비활성화됩니다. 사용자는 다음 위치에서 크로스 도메인 정책 파일을 제공하여 이러한 포트에 대한 액세스를 허용할 수 있습니다.
기본 소켓 연결과 동일한 포트
다른 포트
소켓 서버와 동일한 도메인의 포트 80에 있는 HTTP 서버
기본 소켓 연결과 동일한 포트 또는 다른 포트에서 크로스 도메인 정책 파일을 제공하는 경우, 다음 예제와 같이 크로스 도메인 정책 파일의 to-ports 속성을 사용하여 허용되는 포트를 열거할 수 있습니다.
기본 소켓 연결과 동일한 포트에서 소켓 정책 파일을 가져오려면 단순히 Socket.connect() 또는 XMLSocket.connect() 메서드를 호출합니다. 지정된 도메인이 호출하는 SWF 파일의 도메인과 다른 경우 Flash Player에서는 자동으로 사용자가 연결하려는 기본 연결과 동일한 포트에서 정책 파일을 가져오려고 시도합니다. 기본 연결과 동일한 서버의 다른 포트에서 소켓 정책 파일을 가져오려면, 다음과 같이 특수 "xmlsocket" 구문을 사용하여 Security.loadPolicyFile() 메서드를 호출합니다.
Security.loadPolicyFile() 메서드를 Socket.connect() 또는 XMLSocket.connect() 메서드보다 먼저 호출합니다. 그러면 Flash Player은 정책 파일 요청이 수행될 때까지 기다렸다가 기본 연결을 허용할지 여부를 결정합니다.
소켓 서버를 구현하고 소켓 정책 파일을 제공해야 할 필요가 있는 경우에는 기본 연결을 허용하는 포트와 동일한 포트를 사용하여 정책 파일을 제공할지 아니면 다른 포트에서 정책 파일을 제공할지 여부를 결정합니다. 두 경우 모두 서버는 클라이언트에서 첫 번째 전송을 수행할 때까지 기다렸다가 정책 파일을 보낼지 또는 기본 연결을 설정할지 여부를 결정합니다. Flash Player에서 정책 파일을 요청할 때는 항상 연결이 설정된 직후에 다음 문자열을 전송합니다.
<policy-file-request/>
서버는 이 문자열을 수신한 후 정책 파일을 전송할 수 있습니다. 정책 파일 요청과 기본 연결 모두에 동일한 연결을 다시 사용하지 마십시오. 정책 파일을 전송한 후에는 해당 연결을 닫아야 합니다. 연결을 닫지 않으면, Flash Player에서 기본 연결을 설정하기 위해 다시 연결하기 전에 정책 파일 연결을 닫습니다.
데이터 전송은 SWF 파일의 ActionScript 코드에서 서버 또는 리소스에 데이터를 보낼 때 발생합니다. 네트워크 도메인 SWF 파일에는 데이터 전송이 항상 허용됩니다. 로컬 SWF 파일은 local-trusted 또는 local-with-networking 샌드박스에 있는 경우에만 네트워크 주소로 데이터를 보낼 수 있습니다. 자세한 내용은 로컬 샌드박스를 참조하십시오.
flash.net.sendToURL() 함수를 사용하여 URL로 데이터를 보낼 수 있습니다. 기타 메서드를 사용하여 URL로 요청을 보낼 수도 있습니다. 여기에는 Loader.load() 및 Sound.load()와 같은 로드 메서드,URLLoader.load() 및 URLStream.load()와 같은 데이터 로드 메서드가 포함됩니다.
파일 업로드 및 다운로드
FileReference.upload() 메서드는 원격 서버로 사용자가 선택한 파일의 업로드를 시작합니다. FileReference.browse() 또는 FileReferenceList.browse() 메서드는 FileReference.upload() 메서드보다 먼저 호출해야 합니다.
FileReference.download() 메서드를 호출하면 원격 서버에서 파일을 다운로드할 수 있는 대화 상자가 열립니다.
중요
서버에 사용자 인증이 필요한 경우 브라우저에서 실행 중인, 즉 브라우저 플러그 인이나 ActiveX 컨트롤을 사용하는 SWF 파일만이 인증 및 다운로드에 필요한 사용자 이름과 암호를 요청하는 대화 상자를 제공할 수 있습니다. Flash Player는 사용자 인증을 요청하는 서버에 대한 업로드를 허용하지 않습니다.
호출하는 SWF 파일이 local-with-filesystem 샌드박스에 있는 경우에는 업로드 및 다운로드가 허용되지 않습니다.
기본적으로 SWF 파일은 자체 서버가 아닌 서버에서의 업로드나 다운로드를 시작하지 않습니다. 호출하는 SWF 파일의 도메인에 권한을 부여하는 크로스 도메인 정책 파일이 서버에서 제공되는 경우, SWF 파일은 다른 서버로부터의 업로드 및 다운로드를 허용합니다.
2009/07/06 10:06답글경로를 생각하시면 되요. 위에도 경로에 대한 얘기가 나왔지요. src는 소스가 있는 폴더고 bin 폴더는 컴파일이 된 결과물이 있는 폴더입니다. mp3파일을 찾을때는 결과물이 있는 swf를 기준으로 mp3를 찾습니다.
bin이라는 폴더 아래 Main.swf 라는 파일이 있고 그안에 mp3/Sound.mp3 를 찾는다면 bin 이라는 폴더 기준으로 mp3/Sound.mp3를 찾겠지요. 만약 src/mp3/Sound.mp3 를 bin에서 접근한다면 ../src/mp3/Sound.mp3 로 접근 하셨으면 될 겁니다.
socket.connect(host, 80)을 호출하면 80 포트로 연결하기 전에 host의 843 포트로 연결합니다. 이 포트에는 socket master policy file을 반환하는 서버 애플리케이션이 리슨하고 있어야 합니다. 프로토콜은 다음과 같이 매우 간단합니다.
정책 파일 서버는 843 포트를 리슨하고 있다가 <policy-file-request/> 요청이 들어오면 정책 파일(XML)을 전송하고 소켓을 닫으면 됩니다.
SWF 파일이 소켓으로 연결하고자 하는 곳에 정책 파일 서버가 존재해야 하고, 정책이 tabslab.com 도메인에서 배포된 SWF에 대해서 80 포트만 접속을 허락하니 그 외의 모든 연결은 보안상 오류로 취급됩니다. 따라서 정책 파일 서버가 없거나 정책 파일 서버가 허락하지 않는 from 도메인과 포트로의 접근은 플레시 플레이어 자체가 제한해 버립니다. 아무곳으로의 통신을 막아 보안성을 높이게 되는거죠.
원래의 목적인 소켓 기반 HTTP 업로드를 위해 단계 별로 설명하자면...
(1) 도메인 내에서 업로드를 받는 서버의 방화벽에서 843 포트를 개방합니다.
(2) 정책 파일 서버를 설치한 후 가동시킵니다. Telnet으로 연결 후 <policy-file-request/>를 전송해 올바른 응답을 하는지 테스트합니다.
(3) socket.connect(host, 80)로 연결 테스트합니다.
Security 클래스 메소드
Security.loadPolicyFile( "*" ); 해당 플래시 파일에서 모든 ip주소에 대한 다른 서버에 있는 데이터를 로드할 수 있도록 허용할지 여부를 결정
Security.allowDomain( "*" ); 크로스 무비 스크립팅, 다른 도메인의 SWF파일에 사용권한을 제공합니다. swf파일의 변수, 객체, 속성, 메서드 등을 검사 및 수정할 수 있도록 권한 부여
- Flash Player 보안 모델은 도메인(www.mydomain.com)을 기준으로 한다(보안 Sandbox 모델). - 동일한 보안 Sandbox 내의 리소스끼리는 서로 항상 액세스할 수 있다. - 원격 보안 Sandbox의 SWF 파일에서 로컬 파일이나 데이터에 기본적으로는 액세스할 수 없다. - ActionScript 3 버전으로 작성된 두 SWF 파일끼리는 크로스 스크립팅이 허용된다(이전 버전으로 작성된 SWF 파일과는 LocalConnection 클래스를 사용해 통신한다). - Flash Player는 다음을 각각 서로 다른 도메인으로 간주하므로 보안 Sandbox도 개별적으로 설정해야 한다.
- 서로 다른 보안 Sandbox 내의 리소스끼리 액세스하기 위해서는 다음 두 가지 방법을 생각할 수 있다.
Security.allowDomain() 메서드 사용.
크로스 도메인 정책 파일(Cross Domain Policy File) 사용.
- Flash Player 보안 모델에서는 컨텐츠를 로드하는 것(Loading Content)과 데이터를 액세스하거나 로드하는 것 (Accessing Content as Data or Loading Data)을 구분한다.
컨텐츠 로드: 시각적 미디어에 해당. Loader, Sound, NetStream 등의 클래스 사용.
데이터 액세스 또는 로드: 텍스트, XML 등의 일반 데이터에 해당. URLStream, URLLoader, Socket, XMLSocket 등의 클래스 사용.
2. 권한(Permission) 조절
- Flash Player 보안 모델은 리소스(SWF 파일, 로컬 데이터, URL 등)를 중심으로 설계돼 있다. - 이러한 리소스를 소유하거나 사용하는 Stakeholder는 자신이 소유한 리소스에 대해 보안을 설정할 수 있다. - 각 리소스에는 아래 이미지처럼 4개의 Stakeholder가 존재한다.
2.1 Administrative User Controls
- 모든 사용자에게 영향을 주는 Flash Player 보안을 설정할 수 있다.
mms.cfg 파일: C:\WINDOWS\system32\Macromed\Flash 폴더 내에 존재하며 데이터 로드, 개인정보, Flash Player 업데이트, 전체 화면 모드 등을 제어한다.
Global Flash Player Trust 폴더: C:\WINDOWS\system32\Macromed\Flash\FlashPlayerTrust 폴더로 특정 로컬 SWF 파일에 대한 신뢰 구성 파일을 등록한다. mms.cfg 파일과 달리 SWF 파일을 로컬 시스템에 인스톨 할 때 Global Flash Player Trust 폴더에 신뢰 구성 파일을 등록할 수 있다.
2.2 User Controls
- 현재 로그인한 사용자에게만 영향을 주는 Flash Player 보안을 설정할 수 있다.
The Settings UI and Settings Manager: 특정 도메인의 설정을 쉽고, 빠르게 구성하며 카메라, 마이크, 공유 객체 등을 제어한다. 보다 자세한 사항은 여기를 참조.
User Flash Player Trust 폴더: C:\Documents and Settings\[User Name]\Application Data\ Macromedia\Flash Player\#Security\FlashPlayerTrust 폴더로 특정 로컬 SWF 파일에 대한 신뢰 구성 파일을 등록한다.
2.3 Website Controls (Cross-domain Policy Files)
- 서버에 있는 데이터를 다른 도메인에 있는 SWF 파일에서 액세스하려면 서버에 크로스 도메인 정책 파일 (XML 파일)이 작성돼 있어야 한다. - 서버의 크로스 도메인 정책 파일에 지정된 도메인에 있는 SWF 파일은 해당 서버의 데이터에 액세스가 가능하다.
- 정책 파일은 기본적으로 crossdomain.xml 파일로 서버(웹 서버)의 루트 디렉토리에 존재해야 하나 Security.loadPolicyFile() 메소드를 사용해서 원하는 정책 파일을 불러올 수도 있다. - 루트 디렉토리에 존재하는 정책 파일은 전체 서버에 적용되고, 하위 디렉토리에 존재하는 정책 파일은 해당 디렉토리와 그 하위 디렉토리에만 적용된다. - 모든 도메인에 있는 SWF 파일에서 액세스가 가능하게 허용할 수도 있다.
- HTTPS 프로토콜을 사용하려면 allow-access-from 태그의 secure 특성을 true로 설정한다. 이렇게 하면 HTTPS 웹 서버가 아닌 일반 HTTP 웹 서버 도메인에 있는 SWF 파일에서는 액세스할 수 없다. - 도메인이 다르면 정책 파일도 달라야 한다는 것에 주의한다(mydomain.com과 www.mydomain.com). - 정책 파일은 문서 기반(Loader, Sound, URLLoader, URLStream 등의 클래스) 정책 파일과 소켓 기반 (Socket, XMLSocket 클래스) 정책 파일로 구분한다(소켓 정책 파일은 포트 번호를 지정한다는 게 차이점).
- 1024보다 낮은 포트 번호에 있는 정책 파일은 모든 포트에 대해 액세스를 허용할 수 있고, 1024 이상의 포트 번호에 있는 정책 파일은 1024 이상의 포트에 대해서만 액세스를 허용할 수 있다. - NetStream, LoaderContext, SoundLoaderContext 클래스의 checkPolicyFile 속성을 true로 설정해 각 객체를 로드하기 전에 정책 파일부터 다운로드 받는다.
2.4 Author (Developer) Controls
- Security.allowDomain() 메서드를 사용해서 지정된 도메인에 있는 SWF 파일이 이 메소드를 호출한 서버의 데이터에 액세스할 수 있게 한다. - Security.allowInsecureDomain() 메소드는 사용하지 않는 것이 좋다. - Security.loadPolicyFile() 메소드를 사용해서 기본 정책 파일이 아닌 원하는 정책 파일을 불러올 수도 있다.
3. 보안 Sandbox
3.1 Remote Sandbox
- 웹 상의 리소스에 대한 Flash Player 보안 모델.
3.2 Local Sandbox
- 로컬 리소스에 대한 Flash Player 보안 모델은 다음 중 하나로 적용된다.
Local-with-filesystem Sandbox: 기본 보안 모델. SWF 파일은 로컬 리소스에 액세스할 수 있으나 원격 리소스에는 액세스할 수 없다.
Local-with-networking Sandbox: SWF 파일은 로컬 리소스에는 액세스할 수 없고 원격 리소스에만 액세스 할 수 있다
Local-Trusted Sandbox: SWF 파일은 로컬 리소스나 원격 리소스에 모두 액세스할 수 있다.
- Security.sandboxType 속성을 사용해서 SWF 파일에 적용된 보안 모델을 확인할 수 있다.
4. 네트워크 API 제한
- SWF 파일을 HTML 페이지에 포함할 때 object 및 embed 태그에서 allowNetworking 파라미터를 설정하고 all, internal, none 중 하나를 지정하여 SWF 파일이 네트워크 API를 사용하는 수준을 제어할 수 있다.
- 전체 화면 모드를 사용하려면 Stage 클래스의 displayState 속성을 StageDisplayState.FULL_SCREEN으로 설정한다. - SWF 파일을 HTML 페이지에 포함할 때 object 및 embed 태그에서 allowFullScreen 파라미터를 설정하고 true를 지정한다. - 전체 화면 모드를 사용할 때 주의할 사항은 여기를 참조한다.
6. Stage 보안
- Stage 객체의 속성이나 메서드 일부를 Display List에 있는 Display 객체에서 사용할 수 있다(단, Stage 소유자와 동일한 보안 Sandbox 내에 있어야 한다). - Stage 객체는 첫번째 SWF 파일이 로드되면 소유자(Owner)가 있는 것으로 간주한다.
7. 이벤트 보안
- Display List와 연관된 이벤트(버블링, 캡처)에는 해당 이벤트가 발생한 Display 객체의 Sandbox를 기준으로 보안 설정이 적용된다. - 이벤트는 조상 Display 객체를 통해 마이그레이션 되며 보안 Sandbox가 서로 다를 경우에는 이벤트가 제대로 전달되지 않는다.
8. Legacy 컨텐츠 작업
- Flash Player 6 이하 버전에서는 http://store.mydomain.com이나http://www.mydomain.com을 모두 동일한 도메인으로 취급하기 때문에 ActionScript 3으로 제작된 SWF 파일이 정상적으로 실행되지 않는 문제가 발생한다. - 이럴 경우 Security.exactSettings 속성을 false로 설정하면 Flash Player 6 이하 버전의 방식을 사용하므로 발생 하는 문제를 막을 수 있다.
- SWF 파일을 HTML에 포함할 때 object 및 embed 태그에서 allowScriptAccess 파라미터를 설정하고 always, sameDomain, never 중 하나를 지정하여 SWF 파일이 Outbound Scripting을 수행하는 기능을 제어할 수 있다.
