2008/03/07 - [프로그래밍/Silverlight] - [Silverlight/MSDN] URL Access Policy
와 관련하여, 크로스 도메인 문제를 해결하기 위해 해당 서버에 접근 정책을 설정하는 방법에 대해 설명한 글이에요. 자세한 것은 원문을 보시고 여기에서는 HOW TO 부분만 가져왔습니다.

원문 : How to: Make a Service Available Across Domain Boundaries


실버라이트는 크로스 도메인 접근에 두 가지 매커니즘을 지원합니다.

  • clientaccesspolicy.xml
    ; 크로스 도메인 접근cross-domain-access하기 위한 서비스를 설정하기 위해 도메인의 루트에 놓는 파일.
  • crossdomain.xml
    ; 서비스가 호스트된 도메인의 루트에 놓는 파일. 파일은 반드시 공개할 도메인을 기록해야 합니다. 플래시에서 사용했던 방식으로 실버라이트도 이 스키마의 서브셋을 지원합니다.

clientaccesspolicy.xml 파일을 사용하여 크로스 도메인 접근하기

1. 실버라이트 클라이언트가 접근 가능한 서비스를 만듭니다. 자세한 정보는 실버라이트 클라이언트를 위한 서비스 만들기를 보세요.

2. 서비스에 접근을 허용하기 위해 clientaccesspolicy.xml 파일을 생성합니다. 다음 설정은 다른 어떤 도메인에서도 현재 도메인에 있는 모든 리소스를 접근하도록 허용합니다.

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from>
                <domain uri="*"/>
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
            </grant-to>
        </policy>
    </cross-domain-access>
</access-policy>

3. clientaccesspolicy.xml 파일을 서비스가 호스트되고 있는 도메인의 루트에 저장합니다. 예를 들어, http://fabrikam.com 에서 호스트되고 있는 서비스라면 반드시 http://fabrikam.com/clientaccesspolicy.xml에 위치해야 합니다.

4. 반면, http://contoso.com과 같은 딱 하나의 도메인에서만 접근을 허용하길 원한다면 clientaccesspolicy.xml은 다음과 같은 설정을 포함해야 합니다.

<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from>
                <domain uri="http://contoso.com" />
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
            </grant-to>
        </policy>
    </cross-domain-access>
</access-policy>

5. 다른 도메인에서 서비스를 호출했을 때 접근이 가능한지 테스트합니다.


crossdomain.xml 파일을 사용하여 크로스 도메인 접근하기

1. 실버라이트 클라이언트에서 접근이 가능한 서비스를 만듭니다.

2. 다음 설정을 포함하는 crossdomain.xml 파일을 생성합니다. 파일은 반드시 다른 어떤 도메인에서도 서비스에 접근할 수 있도록 설정해야 하며 그렇지 않을 경우 실버라이트가 해석할 수 없습니다.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

3. 서비스가 호스트된 도메인의 루트에 crossdomain.xml 파일을 서비스가 호스트되고 있는 도메인의 루트에 저장합니다. 예를 들어, http://fabrikam.com 에서 호스트되고 있는 서비스라면 반드시 http://fabrikam.com/crossdomain.xml에 위치해야 합니다.

4. 다른 도메인에서 서비스를 호출했을 때 접근이 가능한지 테스트합니다.

신고
Posted by gongdo

※ 이 문서는 실버라이트 2 Beta 1에만 해당하는 내용으로 Beta 2에서는 다음의 글로 대체 되었습니다. 이용에 착오 없으시길.

2008/06/28 - [프로그래밍/Silverlight] - [MSDN] URL 접근 제약

실버라이트 2에서 가장 크게 바뀐 점 중 하나는 URL 접근에 대한 정책이 기본적인 보안에 대해 안전하면서도 보다 구체적이고 융통성있도록 구성되었다는 점이죠. 특히 실버라이트를 테스트할 때에는 잘 되다가 게시했을 때 안되는 문제의 많은 부분이 바로 URL 접근과 관련하여 일어나는데요, MSDN에 명확하게 정리된 문서가 있어서 번역해봤어요.

원본 : http://msdn2.microsoft.com/en-us/library/cc189008(vs.95).aspx


보안 문제 때문에 마이크로소프트 실버라이트는 쿠키 전달이나 재전송redirection 허용과 같은 보안에 위협이 될만한 것들에 대한 크로스 존Cross-zone, 크로스 도메인, 크로스 스키마 URL 접근을 제한합니다. 예를 들어, 한 웹 도메인에 호스팅된 실버라이트 기반의 애플리케이션을 가지고 있고 WebClient 개체를 사용하여 다른 도메인에 저장되어 있는 파일에 접근을 시도한다면 그 요청은 실패할 것입니다. 다음 테이블에서 이러한 룰을 정리합니다.

Note:
실버라이트로 다른 도메인의 파일을 접근할 수도 있습니다. 그렇게 하기 위해서는 이 기능을 명시적으로 활성화할 필요가 있습니다. 보다 자세한 정보는 여기를 클릭하세요.

  WebClient object Media, images, ASX XAML files, Font files Streaming media
허용된 스키마 HTTP, HTTPS HTTP, HTTPS, FILE HTTP, HTTPS, FILE HTTP
크로스 스키마 접근 No No No HTTPS로부터는 안됨
크로스 웹 도메인 접근 No HTTPS가 아닐 경우 Yes No Yes
크로스 존 접근(Windows에서) No No No No
크로스 존 접근(Macintosh에서) No Yes No Yes
재전송 허용 같은 도메인에서 Yes 같은 도메인에서 No

Note:
이러한 접근 정책의 위반으로 인한 결과로 발생한 에러가 있을 때 그 에러는 아마도 정확한 이유를 가리키지 않을 것입니다.

앞에서 본 표에서 사용된 몇몇 용어의 정의는 다음과 같습니다.

  • 크로스 스키마Cross-scheme : 어떤 스키마(예를 들어 HTTP, HTTPS)에서 다른 스키마를 접근하는 것.
  • 크로스 웹 도메인Cross-Web domain : 어떤 웹 도메인과 다른 웹 도메인 사이의 접근(예를 들어 www.contoso.com에 호스팅된 애플리케이션이 www.fabrikam.com에 있는 콘텐트에 대한 접근을 시도).
  • 크로스 존Cross-zone : 보안 영역간의 접근. 예를 들어 인터넷 서버에서 인트라넷 리소스에 접근을 시도하는 것.

예를 들어, 애플리케이션을 호스트하고 이미지를 다른 서버에서 가져오고 싶다면 앞에서 본 표에 있는 "Media, images, ASX" 항목을 체크해볼 수 있습니다.

  • 만약 애플리케이션이 HTTP 사이트에 호스팅된다면 HTTPS 스키마를 사용한 사이트에서 이미지를 가져올 수 없습니다.
  • 그 도메인의 스키마가 HTTPS가 아닌 한 다른 도메인에서 이미지를 가져올 수 있습니다.
  • 만약 애플리케이션이 인터넷에 있고 사용자가 Mac을 사용하지 않는다면 이미지를 인트라넷에서 가져올 수 없습니다.
  • URL이 같은 도메인에 있는 한 다른 이미지 URL로 재전송할 수 있습니다.

참고

컨셉
미디어 포맷 및 프로토콜 지원(실버라이트 2)
코어 프리젠테이션 프레임워크 / UI

신고
Posted by gongdo

Expression Blend 2.5

Expression 2008.02.29 20:55

놀랍게도, 차기 Expression Blend에 대한 소식을 거쓰리 아저씨가 직접 올렸네요.
First Look at Using Expression Blend with Silverlight 2

실버라이트 2만큼, Expression Blend 2.5도 많은 기능적 향상이 이뤄졌어요. 자세한 내용은 거쓰리 아저씨 블로그를 방문해 보시고 여기에서는 간략하게 둘러보기로 하죠.

드디어 지원되는 기본 컨트롤들! ㅠ.ㅜ
그러나 기본 컨트롤은 어디까지나 기본 컨트롤일 뿐이죠. 진짜 RIA를 지향한다면 아마도 기본 컨트롤을 그대로 사용하는 경우는 많지 않을 거라고 생각해요.

역시 기본으로 지원하는 달력 컨트롤. 그러나 Rich란 말을 붙이기엔 좀 부족해보이죠? ^^ 블렌드를 잘 활용하면 아마도 그리 어렵지 않게 이것보다 훨씬 더 멋진 컨트롤을 디자인할 수 있을 거에요.

한가지 눈여겨 볼 부분은 컨트롤과 디자인 영역 테두리를 연결하는 ∞이런 마크. 네, WPF와 비슷한 앵커, 마진 기능이 들어갈 것으로 기대되네요:D

와우! WPF처럼 그리드 패널도 있고 레이아웃도 굉장히 직관적인 방법으로 구성이 가능하겠네요.

 

자세한 설명은 역시 거쓰리 아저씨 블로그를 참고하면 되겠고 여튼, 중요한 건 블렌드에서 비주얼 스튜디오의 코드 비하인드에서 작성된 데이터에 대해 직접 바인딩을 수행할 수 있게 되었군요. 이건 상상 이상인데요?

또한 Style이라는 엘리먼트를 통해 컨트롤에 대한 템플릿 구성이 가능하게 되었네요. XAML의 진정한 강점은 바로 이런식으로 구조화된 디자인, 구조화된 개발이 가능하게 된다는 것인 것 같아요.

스타일과 템플릿의 활용을 보여주는 인상적인 케이스죠. 아까 실버라이트가 제공하는 기본 컨트롤을 '그대로' 사용하는 경우는 별로 없을 거라고 했죠? 바로 스타일과 템플릿을 잘 활용하면 위와 같이 단지 템플릿을 선택하는 것 만으로도 기존 컨트롤의 기능을 그대로 사용하면서도 룩&필을 변경할 수 있기 때문이죠. 이를 위해 WPF와 같이 애플리케이션과 사용자 컨트롤에 대한 Resources 탭이 부활한 것도 중요한 변화!

거쓰리 아저씨가 얘기했듯이, 이게 다가 아니에요. 또한 이 기능들은 WPF와 실버라이트 모두에서 작동하기 때문에 앞으로 개발자 뿐만 아니라 디자이너도 한번 디자인한 애플리케이션을 데스크탑과 웹 모두에서 '고통없이' 활용 할 수 있는 날이 가까워진거죠!

2008/02/24 - [프로그래밍/Silverlight] - WPF에 가까워지는 Silverlight에서 얘기한 것처럼 실버라이트와 WPF는 서로 가까워지고 있고 이 둘 모두를 디자인할 수 있는 블렌드와 디자이너의 역할은 더 없이 중요할 거에요.

한 가지 아쉬운 점이라면 여전히 SourceSafe나 TFS와의 연동에 대한 얘기는 없네요. 물론, 블렌드의 프로젝트 단위 관리 체계만 해도 디자이너에게 충분히 어색하기 때문에 이런 기능을 넣는다고 해서 크게 얻을 수 있는 장점은 없을 것 같긴 하지만요. 향후 디자이너와 개발자가 원격지에서의 협업도 가능해지려면 이런 기능도 필요하리라 생각되네요.

여튼, 실버라이트 2도 그렇지만 블렌드 2.5역시 변화의 폭이 상당하고 기대도 커요. 처음 툴에 적응하기까지 어느정도 힘든 시기가 있겠지만 이 시기를 극복한다면 강력한 RIA 개발 플랫폼을 얻을 수 있을거라 믿어요.

신고
Posted by gongdo

실버라이트와 관련된 가장 많은 질문 중 하나는 '퍼가기를 어떻게 하나요?' 였죠. 전 이 질문을 받을 때마다 목소리가 작아질 수 밖에 없었어요. 바로, 크로스 도메인에 대한 지독하리만치 철저한 제한으로 iframe 말고는 해결할 방법이 없었기 때문이죠.

패키징

실버라이트 2는 드디어 퍼가기를 가능하게 하는 크로스 도메인 정책과 패키징을 지원하게 되었어요!

실버라이트 2는 프로젝트에 포함된 모든 컴파일 코드와 정적인 리소스(이미지, XAML, 사용자 컨트롤, 동영상 등)를 XAP(ZAP, 잽으로 발음) 파일로 압축하게 되고 전과는 다르게 실버라이트는 아주 심플한 <object>태그를 사용하여 이 XAP 파일을 지정하는 것 만으로 HTML 페이지에 간단하게 올릴 수 있죠.

여기에서도 최근 마이크로소프트의 공개적인 플랫폼 정책을 엿볼 수가 있는데요, 바로 XAP 파일은 특수한 바이너리가 아닌 표준 ZIP 형식이란 것이죠. XAP은 아무 ZIP 압축해제 프로그램으로 그 안에 들어있는 파일들을 풀어볼 수 있게 돼요.

여기에서 아마도 컨텐트의 저작권에 대한 걱정을 할 수도 있을텐데요, 설마 저작권 보호가 필요할 정도로 중요한 컨텐트를 단순히 정적 리소스로 추가할 개발자는 없겠죠? 예를 들어, HTML에 덜렁 img 태그나 embed 태그로 컨텐트를 넣는 것 처럼요. 당연히 저작권 보호가 필요한 컨텐트는 웹서버의 특정 영역에 적절한 보호 수단을 적용하여 보관하게 될 거에요. XAP파일에 같이 넣는게 아니라요.

실버라이트 2는 XAP으로 압축되면서 애플리케이션의 크기와 전송속도를 대폭 향상시킬 수 있게 되었어요. 일단 파일이 한개로 줄어들면서 웹 서버에 대한 요청이 줄어드는 것만 해도 상당한 전송속도 향상을 얻을 수 있죠. 거쓰리 아저씨의 정보에 의하면 현재(Beta1) 가장 단순한 Hello World 예제에 해당하는 XAP파일은 약 4kb에 불과하죠. WOW!

배포

또 한가지 신경쓰지 않을 수 없는 것은 바로 실버라이트 런타임의 배포죠. 실버라이트 1.0에서도 이미 마이크로소프트의 다운로드 링크 방문, 설치 파일의 직접 다운로드 방식을 기본으로 지원하고 동시에 커스터마이징된 어떠한 형태의 배포도 보장하고 있죠. 심지어 원한다면 ActiveX를 사용하여 배포할 수도 있어요. 실버라이트 2도 비슷한 방식을 지원할 것 같지만 아직 정확한 정보는 없네요.

여튼 실버라이트 2는 4.3메가 정도의 배포 용량을 가지고 있고 설치에는 약 4~10초 정도밖에 걸리지 않는 다는군요.

많은 분들이 오해하고 있는 점 중에 하나는 실버라이트가 닷넷 프레임워크를 설치해야 구동된다고 알고 있다는 건데요, 절대로! 그렇지 않아요. 실버라이트 2에 필요한 모든 구성요소는 4.3메가 정도에 불과한 실버라이트 설치 파일에 완전히 통합되어 있어요. (※MAC을 위한 설치 파일은 MAC 환경상 더 클 수도 있다고 들었어요) 실버라이트 런타임은 다른 어떠한 컴포넌트나 프레임워크에의 의존성을 가지고 있지 않다고 다시 한번 강조해요. 이젠 이런 질문은 받지 않았으면 좋겠네요 :-)

크로스 도메인

퍼가기에 있어서 또 한가지 제약은 크로스 도메인 리소스에 대한 접근이었죠. 실버라이트 2는 드디어 크로스 도메인 리소스에 대한 제한도 해제하여 실버라이트 클라이언트가 다른 도메인 상의 리소스와 데이터를 접근할 수 있게 되었어요. 게다가 향상된 네트워킹 지원으로 REST, WS*/SOAP, POX, RSS 및 표준 HTTP 서비스를 사용할 수 있다고 하는군요. 특히 REST와 RSS의 표준 지원은 매시업 애플리케이션을 작성하는 데 가장 핵심적인 요소로 웹서버의 도움 없이도 재밌는 매시업 애플리케이션을 만들고 자유롭게 배포하는데 결정적인 역할을 할 거에요.


후후... 이제 하나 둘 씩 실버라이트 2에 대한 정보가 풀리기 시작하네요. 기대되지 않으세요? 단지 이것만 있는게 아니에요. MIX08이 얼마 안남았네요. 더 놀라운 점들은 MIX08에서 천천히 감상하셔도 될 거에요. :D

신고
Posted by gongdo

토요일, 훈스닷넷의 시삽 MT를 다녀오느라 인터넷을 못했는데 갔다오니 엄청난 글들이 쌓여있네요. 먼저 우리의 거쓰리 아저씨가 포스팅한 First Look at Silverlight 2. ※더 이상 실버라이트 '2.0'이라고 하지 않고 실버라이트 '2'라고 부르는 것에 주의!

일전에 포스팅했던 2007/11/30 - [프로그래밍/Silverlight] - 실버라이트 2.0!
소개와 거의 같고 약간 더 구체적으로 표현했을 뿐이죠. 여기에서 가장 중요한 것은 실버라이트가 WPF에 점점 더 가까워져 간다는 사실인 것 같아요. 심지어 실버라이트 2의 큰 특징 중 하나를 WPF UI Framework라고 표현했을 정도니까요.

이것은 무엇을 의미할까요?

기본적으로 실버라이트가 WPF의 강력한 프레임워크를 지향하고 있다는 것을 시사해요. 바로 실버라이트 2뿐만 아니라 이후의 버전이 어느 정도의 능력을 가지게 될 지 예상해 볼 수 있다는 것 말이죠.

다음으로 클라이언트 프로그래밍과 웹 프로그래밍의 갭이 줄어들고 개발자와 디자이너는 좀 더 일관성있는 작업이 가능해질 것이라는 것을 의미해요. WPF는 이미 XBAP이라는 데스크탑과 웹의 차이를 아무것도 아닌 것으로 만든 서브셋을 가지고 있지만 XBAP은 윈도에서만 동작한다는, 웹 환경에서는 용납하기 어려운 결정적 문제점이 있다는 것이죠. 실버라이트는 XBAP과는 달리 크로스 플랫폼, 크로스 브라우저를 지향하고 실제로 그렇게 구현되어 있어서 XBAP이 실현하지 못한 웹 애플리케이션으로서의 폭넓은 유연성을 가지게 되죠.

특히 실버라이트 2에서는 XAML의 중요한 기능중 하나인 Template을 드디어 지원하게 되고 이것은 기존의 커스텀 컨트롤에서 제공하기 힘들었던 코드와 표현presentation의 분리를 플랫폼 레벨에서 강제하고 보장할 수 있게 되죠. 재사용성reusability이라는 현대적 프로그래밍의 기본 사항이 드디어 디자인의 영역에서까지 일관적인 규칙으로 표현될 수 있다는 말이에요. 이 점에 대해서는 다른 글로 포스팅하고 싶네요.

그러나, WPF가 아니라 실버라이트 1.1을 통해 XAML과 닷넷 프레임워크를 접하게 된 개발자들에게는 많은 혼란과 두려움을 줄 수 있을거에요.

실버라이트 1.0과 1.1에서는 XAML의 엄청난 기능중에서 극히 일부의 기능만을 사용했고 그나마도 정말 사용하기에 쉬운 부분만을 다루었기에 누구나 배우기 쉬웠죠. 하지만 XAML은 결코 배우기에 만만한 언어는 아니에요. XAML로 표현되는 마크업과 닷넷 프로그래밍으로 작성되는 코드 비하인드를 적절한 구조로 설계하고 사용하는 것은 많은 프로그래머에게 익숙하지 않은 일이고 상당한 연습을 필요로 하죠.

어떻게 해야 할까요?

저는 이렇게 제안하고 싶어요. 실버라이트 2 Beta1의 릴리즈를 불과 한 달도 채 남겨놓지 않은 이 시점에서 실버라이트 2를 더욱 잘 사용하고 이해하기 위해서는 WPF에 대해 공부하세요. 분명히 실버라이트 2 Beta1이 릴리즈 되면서 많은 문서들과 글들과 자료가 쏟아지겠지만 대부분의 정보는 -당연히- 영어로 나올거에요. 부담이죠. WPF와 WPF에서 사용되는 XAML에 대해서는 이미 훌륭한 서적들과 더욱 확정적이고 구체적인 MSDN 문서들 그리고 친절하게 한국어로 만들어진 강좌들이 널려있어요. WPF의 구조를 이해하면 실버라이트를 더 잘 이해할 수 있게 되고 나아가 XAML을 더 잘 이해할 수 있게 될 거에요.

만약, 영어로 된 정보에 익숙한 분이라면 굳이 그럴 필요 없이 실버라이트 2를 공부할 수도 있겠죠. 아마도 이 경우는 상당한 경력을 가진 분이라고 예상 할 수 있는데요, 이런 분은 아마도 실버라이트를 통해 WPF로 역주행(?)을 하는 것도 무리는 없을 거에요.

어느 경우든, 실버라이트는 WPF의 서브셋으로서 둘의 차이는 점점 간격을 줄여나갈 것이고 둘 모두 XAML로 표현되는만큼 XAML에 대해 좀 더 깊은 이해가 필요할 거에요.

실버라이트 2와 XAML에 관해서는 하고 싶은 얘기가 정말 많네요. 다음 글에서 뵙죠.

신고
Posted by gongdo


티스토리 툴바