자 아직 MovieStar(Player 버전 9.0.115) -이하 무비스타의 보안관련 옵션악몽은 끝나지 않았다. 뭐.. 악몽이라기 보다는 이건

선물일수도 있겠다는 생각을 가져 본다.

http://blog.naver.com/hiddenid/40045494648 이 글은 한달전쯤에 플레이어 보안정책이 바뀌어서 푸념과 간단하게 나마

처리방법을 포스팅한 적이 있다.  

각설하고 오늘의 이 정보가 필요한 이유가 있었으니..... 일년전쯤에 모기업 "인트라넷 서비스에 들어간 일정관리 프로그램이

정상적으로 작동하지 아니한다~~ 어찌하면 해결할 수 있느냐? 한달전 쯤부터 뭔가 잘 안되는거 같다"........  직관적으로 판단하고

직관적으로 http://blog.naver.com/hiddenid/40045494648 이 문제로 알고 답해줬으나..........ㅡㅡ

가만 생각하니 저 문제가 아니다.. 저건 링크와 익스터널인터페이스 관련 문제, 즉 기능상의 문제지  보여지고 안보여지고의 문제는

아니였다. 적절하게 상황을 분석하고, 환경을 판단해 본다.......분산서비스 환경이다.. 다중서브도메인을 가지고 있다... 서비스하는

위치가 다 다르다..... 여태 서비스는 잘됬었다.... 불과 한달전까지만해도..........   그럼 몇가지로 원인을 좁혀 볼수 있었다.

(물론 내가 생각할 수 있는 범위가 이 정도 밖에 안되므로......ㅡㅡa)

1. 분산서비스, 서브도메인간 발생할 수 있는 크로스도메인간 보안오류

2. 서버&클라이언트간 새로운 보안정책(방화벽, 통신포트변경) 변경

3. 사용 소프트웨어 (Flash 플레이어)의 내부기능변경

4. 서비스 서버 장애

기타여러가지..................

일단 선행배제 조건이......여태 서비스가 잘 되었다는점, 서비스 환경(도메인, 서버등)의 변경이 없었다는점.... 그럼 뭐냐

이것도 flas플레이어의 문제다... ..... 쉽게 해결이 되지않아서 기존 보안관련 문서(http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html)를 찬찬히 훓어 보던 가운데.......

Crossdomain.xml의 기본 옵션이 바뀌었다................................ 는 것을 뒤늦게 인지하였다..  해서 다음과

같이 크로스도메인파일을 수정하여 서버에 Deploy하여 해결봤다...ㅡㅡa

이것이 이전에 서비스하던 크로스도정책파일이다.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE cross-domain-policy SYSTEM "http://adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*.서브.도메인" /> </cross-domain-policy>

바뀐 옵션이 적용된 Crossdomain.xml을 보자

<?xml version="1.0" encoding="UTF-8"?> <cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd"> <allow-access-from domain="*.허용도메인 /> <site-control permitted-cross-domain-policies="all"/> </cross-domain-policy>

가장 크게 바뀐점이라 한다면 DTD가 http://www.adobe.com/xml/schemas/PolicyFile.xsd등의 Schema로 대체되었으며

이로인해 다양한 옵션으로 보안정책을 컨트롤 할 수 있게되었다. 이 스키마들도 Adobe에서 다음과 같은 여러형태로 준비하고있다

http://www.adobe.com/xml/schemas/PolicyFile.xsd http://www.adobe.com/xml/schemas/PolicyFileFtp.xsd http://www.adobe.com/xml/schemas/PolicyFileHttp.xsd http://www.adobe.com/xml/schemas/PolicyFileHttps.xsd http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd

여러가지 요긴하고 알아 둘만한 것들이 많지만. 일단 Meta-policy option을 보자.  

all: All policy files are allowed. This meta-policy is appropriate only for servers that are on the public Internet and do not serve any content that requires login credentials. by-content-type: All policy files whose Content-Type is exactly text/x-cross-domain-policy are allowed. No other policy files are allowed. This meta-policy is only available for HTTP and HTTPS servers. Most HTTP servers provide flexible ways to decide how to assign a Content-Type, so this is the most useful option when it is desirable to permit some policy files, but not others. Common strategies for assigning the text/x-cross-domain-policy type are to specify it for individual locations, thus requiring administrator approval for each policy file; or to assign text/x-cross-domain-policy to any file whose name is crossdomain.xml, thus allowing policy files to exist anywhere, but making it easy to find such files, or filter them during uploads or other content-creation processes. by-ftp-filename: All policy files named crossdomain.xml (i.e., those whose URLs end with /crossdomain.xml) are allowed. No other policy files are allowed. This meta-policy is only available for FTP servers. The required filename cannot be customized. master-only: Only the master policy file, located at /crossdomain.xml, is allowed. none: No policy files are allowed. If this meta-policy is declared in the master policy file, then the master policy file is permitted to exist solely for the purpose of declaring this meta-policy, and any <allow-access-from> directives that it contains will be ignored. none-this-response: This is a special meta-policy that can only be specified in an HTTP response header. It helps prevents this particular HTTP response from being interpreted as a policy file. Unlike all other meta-policies, none-this-response affects only a single HTTP response, rather than declaring an overall meta-policy for the entire server. Also unlike all other meta-policies, none-this-response can appear in combination with any other meta-policy without conflict. When none-this-response and another meta-policy are both present, then the current HTTP response will not be allowed to be a policy file, but the additional meta-policy will be interpreted to be the overall meta-policy for the server. The none-this-response meta-policy is mainly useful when your server contains scripts that you do not want to allow to generate policy files. Since scripts can generally choose the Content-Type of their output, and generate arbitrary HTTP response headers, it would be difficult to filter script output looking for indications that the output represents a legal policy file. Instead, by appending a none-this-response meta-policy header to the output, you help make sure that whatever the script generates, it cannot generate a valid policy file. (In addition, if the script generates its own meta-policy HTTP response header, that cannot force the server to adopt a more open meta-policy than the one you specify, since meta-policy conflicts are always resolved by choosing the most restrictive meta-policy encountered.)

 오역의 소지가.. 다분하여.. 번역은........ 내일모래.ㅎㅎ. 어찌되었건 위에서 보는 것과 같이 디테일한 보안정책을 다룰수 있게되었다

뭔가 사람을 죽일 수 있는 총을 맡기면 그에 대한 책임이 따르듯이.........  개인적으로 책임만 늘어난거 같다... 차라리 총을 주지 말지--a

이렇게 옵션을 두고... 이제는 log파일로 찍어 볼수도 있다... 기존에도 이미 이런 기능이 있었는지 알지 못했지만... 썩 마음에 든다.

에러와 그에 대한 로그를 확인할 수 있기에....

일단 자신의 mm.cfg 의 내용을 약간 수정하여야 한다. mm.cfg 의 파일 위치는 링크 페이지를 참고..

mm.cfg 는 Flash Debugger Player에 대한 로그액션 여부등의 환경을 지정할 수 있지만. 디폴트는 값이 비어져 있다.

파일을 열고 다음과 같이 타이핑한다.

PolicyFileLog=1   # Enables policy file logging PolicyFileLogAppend=1  # Optional; do not clear log at startup

이렇게 하면 mm.cfg 의 같은 경로 아래 policyfiles.txt 확인 할 수 있다. 

_______________________________________________________________________________________________________

붙임말 : 본문글에는 mm.cfg 동일 폴더아래 policyfiles.txt가 생성된다고 설명하고 있으나 OS가 XP인 경우

(나의 경우)는 Flayer가 설치되어 있는

C:\Documents and Settings\사용자계정\Application Data\Macromedia\Flash Player\Logs

에서 실제로그 정보가 저장되어 있다.