How to publish PHP files on Azure

IIS에서 Fast CGI를 통해서 PHP스크립트를 구동할 수 있게 되었습니다.
이와 함께 Azure Service Platform 에서도 역시 CGI 엔진을 통해 PHP를 구동할 수 있습니다.

PHP를 수동으로 설치할 때에는 조금 번거로운 설정들을 했어야 했지만 Web Platform Installer를 사용하면 IIS에 손쉽게 PHP를 설치할 수 있습니다. (이 곳에서 다운로드 받을 수 있습니다.)

초 간단 PHP Azure Publishing하는 방법에 대해 기술해 봅니다. (사실 Azure SDK에 나와있는 문서가 말을 너무 어렵게 써 놓은 지라 ^^)

Visual Studio 를 사용합니다.(무료 버전인 Web Developer 2008 Express 도 가능합니다)

1. Cloud Service 프로젝트 추가

 

2. 추가된 Cloud Service 프로젝트에서 *.csdef 파일 수정하기

3. CGI Web Role 추가하기(Visual Basic / C# 상관없음)

4. WebCGI Role 프로젝트에 php 폴더 만들기

5. PHP CGI 파일들 모두 4번에서 생성한 폴더에 복사하기

Web Platform Installer를 통해 PHP를 설치하셨다면 설치된 PHP의 위치는 %Program Files%\PHP 일 것 입니다.
이곳의 모든 파일들과 하위 폴더들을 그림 4번에서 생성한 php 폴더 밑으로 모두 복사합니다.

6. 추가된 PHP 폴더 아래의 소스 파일들을 프로젝트에 include 하기

 
파일들을 추가한 후 모든 파일들의 프로젝트 속성의 Build Action을 Content로, Copy to Output Directory를 Copy Always 혹은 Copy if newer 로 변경해 줍니다.

7. Web CGI Role의 Web.roleconfig 파일 수정하기

8. Web CGI Role의 Web.config 파일 수정하기

Fast CGI Handler를 Web.config 파일에 추가해 줍니다.

9. Cloud에 게시할 웹 스크립트 추가하기

본 블로그 에서는 간단히 phpInfo(); 를 호출하는 코드가 담긴 PHP 파일을 프로젝트에 추가합니다.

[WebCGIRole 프로젝트에 추가된 test.php 파일 내용]

10. 실행해 보기

이와 같이 실행이 된다면 성공적으로 Dev Fabric에 성공적으로 게시된 것 입니다.

[Dev Fabric에 게시된 예]

*잠깐!
“컴퓨터에 ntwdblib.dll이(가) 없어 프로그램을 시작할 수 없습니다. 프로그램을 다시 설치하여 이 문제를 해결하십시오” 라는 메세지가 보인다면?

PHP 설치 후 SQL Server 용 드라이버를 설치하셔서 그렇습니다.
php.ini 파일에서 extension=php_mssql.dll 항목을 remark 해 주시면 해결 됩니다.

그래도 안 된다면? php 설치 폴더의 ini 파일을 계속 참조하고 있는 듯 싶군요.
-> %program files%\php\php.ini 파일을 잠시 rename 해 주시고 다시 빌드해 주세요.

Dev Fabric에서 테스트 시에서 발생하는 오류이니 걱정하지 않으셔도 됩니다.

11. Cloud 에 게시

 
[게시 중….]

[Production 환경으로 publish]


[Cloud 환경에서의 실행 예]

IIS.net 사이트를 뒤지다가 IIS Quick Guides (http://learn.iis.net/page.aspx/341/quick-guides/)  링크 자료를 찾았다.
오호 이것 봐라.. 내부 machanism을 이해하기에는 부족해도 운영 가이드로 이용하기에는 부족함이 없어 보인다.
한글로 하나 멋지게 번역되어 나와주면 좋겠다 싶어서 보니… 대부분의 항목들이 한글화 되어 있다.

영문이라 투덜대는 개발자들에게도 좋을 듯 싶다.

각 항목들은 대게 Technet의 아티클들과 연결되어 있다. 그런데 이 아티클들의 링크를 보면 중간에 en-US라고 하는 부분이 있다.(바로 어떤 언어로 보여질 것인가를 결정하는 파라메터 되겠다.)

예) Installing and Configuring Servers - http://technet.microsoft.com/en-us/library/cc755183.aspx

요기서 살짝 en-US를 ko-KR로 바꿔줘 보자. – 그러면 다시 redirection 되면서 한글화된 내용을 볼 수 있다. http://technet.microsoft.com/ko-kr/library/cc755183(WS.10).aspx

예상외로 현업에서 개발자건 시스템 운영자건 간에 IIS에 대한 이해가 높지 않다.

Recycling의 Sexy함도 WorkerProcess 의 융통성과 Kernel Level Processing의 강력함도 이해하지 못한 채 예전 IIS 4.0 수준의 이해로 일관하는 게으른 개발자들이 주변에 너무 많다.

IIS가 불안정하고, 제한적이라고? 제발 좀 들여다 보자. 얼마나 돈 들여 사용할만한 구조를 가지고 있는 것인지 말이다.
 
그저 가상디렉토리 하나 만들어, 웹 어플리케이션 하나 만들어 웹 컨텐츠들을 호스팅하기에는 IIS의 기능들이 너무나 아깝다.

이건 마치 포스쉐를 오토기어로 운전해 주시는 센스 없는 운전자와 다를 바가 없다.

구조를 조금 더 알고 싶은 개발자들은 참조하자.

☞ IIS 6.0 기술개요 백서 - 기술백서 다운로드 (반드시 읽고 이해하자)
☞ Introduction to IIS 7.0 Architecture - http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/
☞ 한글화 된 MSDN 아티클 – Windows Vista 및 그 이상의 웹 서버를 위한 탐색 http://msdn.microsoft.com/ko-kr/magazine/cc163453.aspx

IIS 제대로 이해하고 써 보자. 잘 튜닝된 웹 서버 한대 세 서버 안 부럽다!

클라우드 컴퓨팅 환경 구축을 위한 Identity 서비스의 시작 - Geneva Framework

클라우드 컴퓨팅에 대한 많은 소개들과 관심들이 지천이다. 많은 이들이 클라우드 컴퓨팅을 외치지만 Identity가 보장되지 않는 클라우드는 Hosting Computing의 짝퉁일 수 밖에 없다.

Microsoft Azure Service Platform에서 역시 가장 기본이 되야 할 부분이 바로 Identity.
이를 위해 지원되는 서비스를 쉽게 사용할 수 있도록 지원되는 것이 Genava Framework 이다.

하지만 멋진 PPT Sheet 를 통해서만 봤었지, 실제 테스트 환경을 구축하는 것도 실제 운영환경을 접해보는 것도 쉬운 일이 아니였다. 사실 Microsoft Internal로 VPC 이미지 4개로 릴리즈된 버전이 있긴 했으나 이 역시 구동을 위해서는 만만치 않은 하드웨어 리소스와 설정을 위한 리소스가 필요했다.

반갑게도 금번에 일반 개발자들을 위한 데모가 다가가기 쉽고 이해하기 쉽도록 새로 릴리즈 되었다.

FabrikamShipping - http://code.msdn.microsoft.com/FabrikamShipping

원래 이 데모의 시작은 작년 PDC에서 발표됐었던 Identity Roadmap for Software + Services 의 예제이다.(Must See! - http://channel9.msdn.com/pdc2008/BB11/)

어플리케이션 환경이 점차 On Premise 에서 Hosting, Cloud로 변화해 가는 과정에서 반드시 개발자로써 알아두어야 할 부분이라 생각한다.

*올해 초엔가 언젠가 인터넷상에서의 Identity Service에 대해 정리해 포스팅 하겠다고 큰소리를 쳐 놓고선 아직도 머릿속만 무겁다.

미국의 유명한 사진 공유 사이트인 Photobucket 이 이번에 Silverlight과 Windows Live Web Messenger Toolkit을 이용한 새로운 visual search 사이트를 오픈 했습니다. - http://photobucket.com/visualsearch

제가 몇 차례에 나눠 소개한 Windows Live Web Messenger Toolkit을 사용하여 이용자가 검색한 사진을 곧바로 메신저 상의 친구들과 공유하고 메세지를 주고 받을 수 있도록 하는 기능을 제공하고 있습니다.

기존처럼 미디어 컨텐츠에 대한 링크를 이메일로 상대에 전달해 주는 방식보다 실시간으로 메신저 친구에게 미디어 리소스 링크를 전달하고 이에 대한 의견이나 느낌을 공유할 수 있도록 해 주기 때문에 사용자의 realtime activity 높일 수 있을 뿐만 아니라 웹 사이트의 트래픽 향상에도 효자 노릇을 할 수 있습니다.

게다가 HTML 와 Javascript 기반으로 구성되므로 더 이상 클라이언트에 메신저가 설치가 되어 있네, 맥이네, 리눅스네 할 것 없이 브라우저만 지원되는 환경이라면 얼마든지 친구들과 메세징을 진행할 수 있어 “플랫폼 중립”을 부르짖는 업계에게도 아주 좋은 선택이 될 수 있으리라 생각합니다.

 
[웹 메신저에 로그인]


[친구와 공유하기]

[사진을 공유 받은 친구의 메신저 화면]

이전에 라이브 메신저 Activity SDK를 통해 구현했었던 IMThis(메신저 보내기) 기능들을 이제는 쉽게 HTML 과 Javascript만을 가지고 구현할 수 있게 된 거죠.

Windows Live Messenger Activity SDK를 고려하고 있는 곳이라면, 웹 사이트를 보다 Social 하게 만들 수 있는 방법은 없을까 고민하고 계신 곳이라면 고려해 보실 가치가 충분하다고 생각합니다.

기다리던 Small Basic의 다섯 번째 릴리즈인 Small Basic v0.5 CTP가 public 하게 오픈 되었습니다.
추가된 기능들은 커뮤니티를 통해 요청되어 오던 것들 중심이라고 하네요.

다들 다운로드 받으러 클릭! http://msdn.microsoft.com/en-us/devlabs/cc950524.aspx

변경된 사항들이 궁금하시면 다음의 링크를 참조하세요~http://blogs.msdn.com/smallbasic/
새로 태어날 제 딸에게 Small Basic을 가르쳐 보면 어떨까 하는 (안사람 들으면 싫어할) 상상을 해 봅니다.

Small Basic의 Turtle Graphics와 MS Robotics studio와 연결을 해 보면 어떨까 하는 생각을 하는데 어떨까요, 재미있지 않겠어요?

윈도우 라이브 메신저 웹 툴킷 – 라이브 메신저의 모든 것을 웹에서

이번 글에서는 간단한 예제를 만들어 보면서 라이브 메신저 툴킷의 웹 컨트롤들을 자세히 살펴봅니다.

앞서 두 번째 포스팅(Part2)에서 메신저 UI 컨트롤 각각에 대해 소개해 드렸습니다만, 실제 구현에 대해서는 이번 글을 통해 알아 보도록 합니다.

이 글을 통한 구현에 앞서 여러 컨트롤들을 동적으로 조작해 보면서 익힐 수 있는 Messenger Interactive Toolkit을 미리 살펴 두시는 것도 도움이 될 것 입니다.
(링크를 따라 사이트에 가셔서 learn 을 클릭하시면 각 컨트롤들의 기능들에 대해 직접 값들을 변경해 가면서 쉽게 익힐 수 있는 페이지를 찾을 수 있습니다.)

[그림처럼 learn 을 클릭!]

이 글을 통해 구현해 볼 것은 사용자가 메신저에 로그인을 해서 현재 온라인 상태의 메신저 친구들을 나열하고, 이 친구들을 클릭하면 Live home Profile 페이지로 이동하는 기능을 가진 페이지 입니다.

아래의 동영상에서 보시는 기능을 구현 합니다.

이제 아래의 순서에 따라 차례로 구현을 시작해 봅니다.

Step 1. 기본 설정
지난 테스트에서 사용했던 예제 프로젝트를 기준으로 진행합니다.
기본적으로 필요한 파일들을 꼽아 보자면,

> Channel.html
> Privacy.html
> RefreshMessengerToken.aspx
> Web.config

다음과 같은 파일들이 필요합니다. 각각의 기능들이 뭐냐고 물어보시는 분은 없겠죠? [ 있어요? => 클릭 ]

Step 2. AppVarifier를 생성 위한 페이지 설정
프로젝트에 새로운 웹 폼을 추가해 주시고 페이지 이름을 MyOnlineBuddies.aspx 로 해 줍니다.

그리고 페이지의 vb 혹은 c# 파일에 다음과 같이 코드를 추가합니다. 이 글에서 .net 을 사용한다고 해서 여러분들 역시 그럴 필요는 없습니다.
앞서 소개해 드린 것처럼 Java/Ruby/Phython/Pearl/php 어떤 언어든 상관없이 구현이 가능합니다.

 1:Imports WindowsLive

 2: Partial Class MyOnlineBuddies

 3:Inherits System.Web.UI.Page

 4:  

 5:Private wll As WindowsLiveLogin
= New WindowsLiveLogin(True)

 6:  

 7:'''
<summary>

 8:'''
Gets an application verifier token.

 9:'''
</summary>

 10:'''
<returns>The application verifier token</returns>

 11:ProtectedReadOnlyProperty ApplicationVerifier() AsString

 12:Get

 13:Return wll.GetAppVerifier()

 14:EndGet

 15:EndProperty

 16:End Class

 1:using System;

 2:using System.Web;

 3:using System.Web.Configuration;

 4:using WindowsLive;

 5:  

 6:///
<summary>

 7:///
Class for handling Default.aspx code behind.

 8:///
</summary>

 9:publicpartialclass MyOnlineBuddies:
System.Web.UI.Page

 10: {

 11:private WindowsLiveLogin
wll = new WindowsLiveLogin(true); 

 12:  

 13:///
<summary>

 14:///
Gets an application verifier.

 15:///
</summary>

 16:publicstring ApplicationVerifier

 17: {

 18: get

 19: { 

 20:return wll.GetAppVerifier(); 

 21: }

 22: }

 23: }

Step 3. HTML 페이지 기본 설정

메신저 툴킷의 HTML UI 컨트롤은 XHTML 형식으로 구현되어 있다고 말씀 드린 것 기억하시죠?
이 컨트롤들을 사용하기 위해 우리는 HTML 정의부에 네임스페이스를 추가해 주어야 합니다.

1. 다음과 같이 HTML 선언부를 변경해 줍니다. (이건 다 이미 우리가 살펴 본 내용들이죠)

 1:<htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:msgr="http://messenger.live.com/2009/ui-tags">

2. 이어서 UI 컨트롤들이 사용하게 될 자바스크립트 라이브러리들을 로딩합니다.

 1: <head
runat="server">

 2: <title></title>

 3: <script
type="text/javascript" src="http://www.wlmessenger.net/api/3.0/loader.js"></script>

 4: <script
type="text/javascript" language="javascript">

 5:Microsoft.Live.Core.Loader.load(['messenger.ui', 'messenger.ui.styles.core']);

 6: </script>

 7: </head>

3. 그리고 마지막으로 메신저 AppTag를 추가해 줍니다.

 1:<body>

 2:<msgr:appid="appTag"

 3:application-verifier-token="<%=
ApplicationVerifier %>"

 4:privacy-url="Privacy.html"

 5:channel-url="Channel.html"

 6:token-url="RefreshMessengerToken.aspx">

 7:</msgr:app>

 8:</body>

여기까지는 제 앞선 글을 순서대로 읽어 주신 분들이라면 쉽게 이해하실 수 있는 부분입니다.
여기에다가 <msgr:bar></msgr:bar> 태그만 붙어주면 페이지 하단에 웹 메신저를 호스팅 할 수 있었습니다.

이번에는 이 웹바 컨트롤 대신 로그인 기능, 온라인 친구목록 가져오기 기능등을 직접 구현해 보고자 합니다.

Step 4. 컨트롤 추가하기
메신저 AppTag 뒤에 다음과 같이 Sign In 컨트롤을 추가해 줍니다.

 1:<msgr:sign-in></msgr:sign-in>

여기까지 진행 한 상태에서 한번 페이지를 실행해 봅니다.

Sign In 버튼이 보이고, 클릭 하여 로그인을 진행하면 갑자기 Sign In 버튼이 사라져 버린 것을 확인 하셨나요?

Sign In 버튼은 사용자가 메신저에 로그인 되어 있지 않은 경우 로그인을 하도록 유도하는 버튼입니다.
내부적으로는 앞서 살펴 보았던 msgr-consent-token 과 msgr-delegation-token 유무를 체크하여 이 쿠키들이 없는 경우에만 로그인 버튼을 보이는 로직이 구현되어 있을 것 이죠

로그인 성공과 함께 로그인 버튼이 보이지 않는 것은 당연합니다.

자, 이제 브라우저를 닫고 이어서 Profile 컨트롤을 추가해 봅니다.  cid 값에 $user를 지정해 주었습니다.

 1:<msgr:profilecid="$user"></msgr:profile>

cid 값에 특정 사용자의 cid를 지정해 주면 해당 사용자의 대화명과 오늘의 글이 그리고 메신저 이미지가 보이며, Profile 정보 페이지로 이동할 수 있는 링크가 보입니다. 여기서 $user 란 현재 로그인 한 사용자를 뜻 합니다.
즉, 나의 Profile을 보여주겠다는 뜻이죠.

컨트롤을 페이지에 추가하셨다면 다시 페이지를 실행해 봅니다.

처음에는 No name(Offline) 이라고 쓰여진 화면이 Sign In 버튼 아래로 보이다가, 로그인을 하면 Sign In 버튼은 사라지고 여러분의 메신저 대화명과 이미지가 보이는 것 확인 하셨나요?

Sign In 컨트롤의 경우에는 로그인 전에 보이다가 로그인과 함께 사라지는 것처럼 Profile 컨트롤의 경우에는 사용자의 로그인 이후에 나타나게 하는 것이 좋을 것 입니다. 좀 썰렁해 보이는 것이 차라리 보이지 않는 편이 나을 테니까요. 

[썰렁한 로그인 전에 보이는 Profile 컨트롤 – 영 어색하다. 차라리 로그인 이전에는 보이지 않는 편이 낫다.]

로그인 전에는 Sign In 버튼만 보이다가, 로그인과 동시에 Profile 컨트롤이 보이게 하면 깔끔하게 떨어지는 UI가 나오게 될 껍니다.
 
[로그인 전에는 Sign In 버튼만 보이다가 로그인과 함께 Profile 컨트롤이 보임]

그래서 고안된 컨트롤이 바로 “If 컨트롤” 입니다.
바로 적용 들어갑니다.

 1:<msgr:sign-in>

 2:</msgr:sign-in>

 3:<msgr:ifcid="$user"condition="online">

 4:<msgr:profilecid="$user">

 5:</msgr:profile>

 6:</msgr:if>

위의 HTML Tag 와 같이 Profile 태그를 <msgr:if> 태그로 감쌉니다.
그리고 이 태그에도 역시 cid 를 $user로 지정하고, condition 값을  “online”으로 설정합니다.
말 그대로 “로그인 한 사용자가 온라인이라면 보여줘라” 라고 하는 이야기가 되겠지요.

이와 같이 수정 하신 후 다시 실행 시키시면 로그인 전에는 Sign In 버튼만, 로그인 이후에는 Profile 컨트롤만 보이게 됩니다.

이 Profile 컨트롤은 사용자의 Presence 정보를 변경하거나 로그 오프를 할 수 있는 기능 그리고 “오늘의 한마디” 를 변경해 줄 수 있는 기능을 제공합니다. 
Profile 컨트롤의 cid는 현재 로그인 한 사용자 $user 로 설정되어 있지만 이 값을 커뮤니티의 회원들의 CID로 바꿔 줄 수 있다면?

아래 그림과 같은 재미있는 기능들을 쉽게 구현 할 수 도 있습니다.
 
위의 그림은 사진 공유 사이트에 메신저 웹 툴킷의 UI 컨트롤을 구현해 놓은 예제입니다. 댓글을 단 커뮤니티 회원들의 메신저 사진 이미지와 대화 명들이 보입니다. 사용자들의 메신저 사진들이 보이는 것이기 때문에 사용자가 자신의 메신저 사진을 변경하면 이에 따라 동적으로 변경된 사진과 대화명 등이 보이게 됩니다. 

여기까지의 구현으로 일단 간단히 메신저 웹 툴킷의 컨트롤을 통해 웹 상에서 메신저 상에 로그인 하고, 로그인이 성공하면 나의 Profile 컨트롤이 보이는 기능까지 완성되었습니다.

자 이제는 로그인과 함께 메신저에서처럼 내가 등록한 친구들 중 현재 온라인인 친구들의 목록을 얻어내어 동적으로 리스트 하는 기능을 구현할 차례 입니다.

지금까지는 간단히 태그를 배치하는 것 만으로 쉽게(?) 기능을 구현했습니다만, 이번 기능들부터는 약간의 주의가 요구됩니다.

일단 아래와 같이 HTML 을 구성해 줍니다.

 1:<body>

 2:<msgr:appid="appTag"application-verifier-token="<%=
ApplicationVerifier %>"privacy-url="Privacy.html"

 3:channel-url="Channel.html"token-url="RefreshMessengerToken.aspx"onauthenticated="OnAuthenticated"

 4:onsignedout="OnSignout">

 5:</msgr:app>

 6:<divid="layout"style="text-align:
center; font-family: Tahoma, 맑은 고딕">

 7:<tablestyle="border-width:
medium; width: 500px; border-style: solid;"align="center">

 8:<tralign="center">

 9:<td>

 10:<!--
Show display picture -->

 11:<msgr:ifcid="$user"condition="online">

 12:<msgr:profilecid="$user">

 13:</msgr:profile>

 14:</msgr:if>

 15:<!--
Show sign-in control -->

 16:<msgr:sign-in>

 17:</msgr:sign-in>

 18:</td>

 19:</tr>

 20:<tralign="left">

 21:<td>

 22:<divid="list"style="font-size:
8pt; padding-left: 7px; height: 500px; overflow: auto">

 23:</div>

 24:</td>

 25:</tr>

 26:</table>

 27:</div>

 28:</body>

기본적으로 우리가 앞서 구현한 Sign In 컨트롤과 Profile 컨트롤이 If 컨트롤과 함께 배치된 것은 변함이 없습니다. 좀 예쁘게 다듬기 위해서 컨트롤들을 Table 내부에 배치 시켜 두었습니다.

주의 깊게 보셔야 할 부분은 먼저 appTag 부분입니다.

이전의 appTag와는 달리 onauthenticated 와 onsignedout 이라고 하는 부분이 추가 되었습니다.
appTag는 기본적으로 요구되는 application-verifier-token, privacy-url, channel-url, token-url 이외에 사용자가 인증을 받고, 로그인을 하는 과정상에서의 이벤트들을 처리할 수 있는 기능이 지원됩니다.[기능 전부 보기]

우리는 이 기능들 중 인증이 성공적으로 완료되었을 경우의 이벤트와 로그 오프(SignOut) 할 경우의 이벤트를 사용할 예정입니다. 
두 이벤트들에 대해 소스에서는 OnAuthenticated 와 OnSignout callback 함수들이 지정 되어 있는 것을 보실 수 있습니다.

그러면 이제 각 이벤트 콜백 함수들과 이와 함께 HTML 요소들을 동적으로 구성하기 위한 기능들을 구현할 스크립트 코딩을 완성해 봅니다.

HTML 부분과 마찬가지로 일단 스크립트 부분의 전체 소스를 아래와 같이 구성합니다.

 1: <head
runat="server">

 2: <title></title>

 3: <script
type="text/javascript" src="http://www.wlmessenger.net/api/3.0/loader.js"></script>

 4: <script
type="text/javascript" language="javascript">

 5:Microsoft.Live.Core.Loader.load(['messenger.ui', 'messenger.ui.styles.core']);

 6:  

 7: onlineContacts
= []; //online contacts 들을 담을 배열

 8: timerID
= null;

 9:  

 10:///
인증이 완료되면 호출 된다.

 11:///
인증이 되면 User 객체를 받아서 로그인 한 사용자의 온라인 Contact들을 배열에 담을 수 있도록 collectionChanged 이벤트에 Subscription

 12:function OnAuthenticated(sender,
e) {

 13: _user
= Microsoft.Live.Messenger.UI.Tags.TagsFactory.get_user();

 14: _user.get_onlineContacts().add_collectionChanged(onOnlineContactsChanged);

 15:///
collectionChanged 마다 Display를 변경하게 되면 너무나 빈번하게 호출이 되는 문제가 있어,

 16:///
특정 Interval을 명시적으로 정의하여 온라인 사용자들을 갱신하도록 한다.

 17:///
이 예제에서는 5초마다 Refresh 한다.

 18: timerID
= setInterval(displayBuddies, 5000);

 19: }

 20:  

 21:function OnSignout(sender,
e) {

 22: clearInterval(timerID);

 23: clearlist();

 24: }

 25:  

 26:///
온라인 사용자들을 Display 한다.

 27:function displayBuddies()
{

 28: clearlist();

 29:for (var i
= 0; i < onlineContacts.length; i++) {

 30:if (onlineContacts[i].length
!= undefined)

 31: addlist(onlineContacts[i][0].get_cid());

 32: }

 33: }

 34:  

 35:///온라인
사용자들에 대한 CollectionChanged 이벤트가 발생 시 호출됨

 36:///onlineContacts
배열에 사용자 정보를 추가,삭제, 갱신함.

 37:function onOnlineContactsChanged(sender,
e) {

 38:switch (e.get_action())
{

 39://추가 

 40:caseMicrosoft.Live.Core.NotifyCollectionChangedAction.add:

 41: onlineContacts.splice(e.get_newStartingIndex(),
0, e.get_newItems());

 42:break;

 43://삭제 

 44:caseMicrosoft.Live.Core.NotifyCollectionChangedAction.remove:

 45: onlineContacts.splice(e.get_oldStartingIndex(),
e.get_oldItems().length);

 46:break;

 47://재갱신 

 48:caseMicrosoft.Live.Core.NotifyCollectionChangedAction.reset:

 49: onlineContacts
= new Array(sender.get_count());

 50:for (var i
= 0; i < sender.get_count(); i++) {

 51: onlineContacts[i]
= sender.get_item(i);

 52: }

 53:break;

 54: }

 55: }

 56:  

 57:///
DIV tag 내의 Child 요소들을 삭제

 58:function clearlist()
{

 59:var node
= document.getElementById("list");

 60:if (!node)
{

 61:return;

 62: }

 63:  

 64:while (node.hasChildNodes())
{

 65: node.removeChild(node.firstChild);

 66: }

 67: }

 68:  

 69:///
Messenger Web Toolkit UI 요소를 동적으로 생성하여 추가한다

 70:function addlist(contactID)
{

 71:if (contactID
== '') return;

 72:var tag
= Microsoft.Live.Messenger.UI.Tags.TagsFactory.createTag('display-name',
{ cid: contactID });

 73: document.getElementById("list").appendChild(tag);

 74: tag
= Microsoft.Live.Messenger.UI.Tags.TagsFactory.createTag('personal-message',
{ cid: contactID });

 75: document.getElementById("list").appendChild(tag);

 76: document.getElementById("list").appendChild(document.createElement('br'));

 77: }

 78: </script>

 79: </head>

앞 서 작성한 HTML Tag 부분과 위의 Script 부분을 모두 완성시키면 앞서 동영상 클립에서 본 것과 같은 예제 어플리케이션이 구동되는 것을 확인 하실 수 있습니다.

그러면 이제 자바 스크립트 소스를 자세히 살펴보도록 합니다.
가장 먼저 AppTag 중에서 OnAuthenticated 이벤트의 Callback 함수인 OnAuthenticated 의 내부를 살펴 봅니다.
사용자가 로그인 버튼을 클릭하고 로그인을 정상적으로 마치면 가장 먼저 호출되는 콜백 함수가 바로 OnAuthenticated 입니다.

 1:///
인증이 완료되면 호출 된다.

 2:///
인증이 되면 User 객체를 받아서 로그인 한 사용자의 온라인 Contact들을 배열에 담을 수 있도록 collectionChanged 이벤트에 Subscription

 3:function OnAuthenticated(sender,
e) {

 4: _user
= Microsoft.Live.Messenger.UI.Tags.TagsFactory.get_user();

 5: _user.get_onlineContacts().add_collectionChanged(onOnlineContactsChanged);

 6:///
collectionChanged 마다 Display를 변경하게 되면 너무나 빈번하게 호출이 되는 문제가 있어,

 7:///
특정 Interval을 명시적으로 정의하여 온라인 사용자들을 갱신하도록 한다.

 8:///
이 예제에서는 5초마다 Refresh 한다.

 9: timerID
= setInterval(displayBuddies, 5000);

 10: }

 1:///온라인
사용자들에 대한 CollectionChanged 이벤트가 발생 시 호출됨

 2:///onlineContacts
배열에 사용자 정보를 추가,삭제, 갱신함.

 3:function onOnlineContactsChanged(sender,
e) {

 4:switch (e.get_action())
{

 5://추가 

 6:caseMicrosoft.Live.Core.NotifyCollectionChangedAction.add:

 7: onlineContacts.splice(e.get_newStartingIndex(),
0, e.get_newItems());

 8:break;

 9://삭제 

 10:caseMicrosoft.Live.Core.NotifyCollectionChangedAction.remove:

 11: onlineContacts.splice(e.get_oldStartingIndex(),
e.get_oldItems().length);

 12:break;

 13://재갱신 

 14:caseMicrosoft.Live.Core.NotifyCollectionChangedAction.reset:

 15: onlineContacts
= new Array(sender.get_count());

 16:for (var i
= 0; i < sender.get_count(); i++) {

 17: onlineContacts[i]
= sender.get_item(i);

 18: }

 19:break;

 20: }

 21: }

 1:///
Messenger Web Toolkit UI 요소를 동적으로 생성하여 추가한다

 2:function addlist(contactID)
{

 3:if (contactID
== '') return;

 4:var tag
= Microsoft.Live.Messenger.UI.Tags.TagsFactory.createTag('display-name',
{ cid: contactID });

 5: document.getElementById("list").appendChild(tag);

 6: tag
= Microsoft.Live.Messenger.UI.Tags.TagsFactory.createTag('personal-message',
{ cid: contactID });

 7: document.getElementById("list").appendChild(tag);

 8: document.getElementById("list").appendChild(document.createElement('br'));

 9: }

 1:function OnSignout(sender,
e) {

 2: clearInterval(timerID);

 3: clearlist();

 4: }

간만의 회합.
짧았지만 반가운 얼굴들...

http://www.minij.com/367

• UUID is a hash of PUID + ApplicationID.
  The purpose is to force 3^rd party websites, who has no legal obligations to Microsoft to consume UUID, thus protecting user’s PUID from being abused.

• CID is a hash of PUID + RegistrationDate. (RegistrationDate is only known to the backend.)
  The purpose is to prevent PUID from being exposed, therefore CID is used in its place. You can safely expose CID on query strings or in URLs. Since CID has a 1:1 relationship to PUID, it has all characteristics of PUID, minus the PII impact.

윈도우 라이브 메신저 웹 툴킷 – 라이브 메신저의 모든 것을 웹에서

지난 글 마지막에서 말씀드린 것처럼 이번 글에서는 윈도우 라이브 메신저 웹 툴킷의 인증 방식에 대해 알아보도록 합니다. 
앞서 소개드렸던 두 개의 쿠키 – msgr-consent-token 과 msgr-delegation-token 기억 나시나요?

뜻 그대로 풀어 보자면 첫 번째 쿠키는 “허용/허가” 라는 뜻을 가진 쿠키이고 두 번째 쿠키는 “위임/대리” 라는 뜻을 가진 쿠키 되겠습니다.
무슨 허용이고, 무슨 위임이지?

이 두 쿠키들이 무엇을 뜻 하는지를 알게 되면 이 의문이 모두 해결됩니다.

기억을 더듬어 우리가 웹 메신저에 로그인 하던 과정을 주의 깊게 살펴 봅니다.

로그인 버튼을 클릭하면 아래 보이는 창이 팝업 됩니다. 이 창에서 붉은 색으로 박스 쳐진 부분을 보시면,
“귀하께서 www.wltoolkit.com 에 방문하시면 자동으로 메신저에 로그인 됩니다. 그게 뭔 말이냐?” 라고 하는 부분을 보실 수 있습니다.

”어라 난 그냥 로그인 하려고 한 것 뿐인데 무슨 자동 로그인?” 하실 분 들 계실 겁니다.
또 “난 이거 했는데도 자동 로그인 안되던데 무슨 소리냐?” 라고 하실 분들 또한 계실 겁니다. 

“그게 뭔 말이냐” 라는 링크 클릭해보시면 설명되어 있는 것과 같이 마이크로소프트 사이트는 아니지만 Windows LiveID 와 연결을 시켜 특정 사이트에 로그인을 하면 자동으로 메신저에도 로그인 할 수 있도록 해 주겠다고 하는 것 입니다.

즉, “내가 이 사이트에 로그인 하면 자동으로 메신저에도 자동 로그인 할 수 있도록 허용해 주겠다” 라고 하는 이야기가 됩니다.

이것을 바로 “consent” 라 합니다.

사용자가 별도로 Windows Live ID에 아이디와 패스워드를 입력하지 않아도 자동으로 윈도우 라이브 아이디 계정을 통해 메신저에 로그인 을 시키겠다라는 이야기가 되는 거죠.

제가 지난 글의 마지막에 읽어 주십사 부탁 드렸던 저의 이전 포스팅 에서 말씀 드렸던 위임인증이 바로 사용된 예가 바로 윈도우 라이브 웹 툴 킷 입니다.
또한 위임했다라고 하는 증거로 필요한 토큰이 위임토큰 – Delegated Token – 이 되는 것 이지요. (앞의 글에서 제가 놀이동산 손목 띠, 클럽의 손목 도장 이야기 했던 것 기억 하시나요?)


정리해 보면

- 허용토큰(Consent Token) - msgr-consent-token 은 자동 로그인을 허용했다는 증거로 받은 토큰.

- 위임토큰(Delegated Token) - msgr-delegation-token 은 나중에 로그인이 필요할 경우 인증 여부를 재 확인 시켜 주기 위해 위임을 받았다는 증거로 제공해야 할 토큰

으로 구분할 수 있습니다.
 
자동으로 사용자를 메신저에 로그인 할 수 있도록 하기 위해서는 허용 토큰(Consent Token)을 웹 사이트의 데이터 베이스에 저장시킨 뒤 사용자가 다음 번 방문 시에 이 두 개의 토큰(Consent Token / Delegated Token) 을 쿠키에 설정해줌으로써 사용자를 대신해서 메신저에 로그인을 시켜주게 되는 것이지요.

이와 같은 방식의 로그인을 허용 토큰을 통한 위임 로그인(Stored Consent Tokens for Delegated Authentication) 이라고 합니다.
사용자는 단 한번의 허용을 마치면 그 뒤로는 별도로 윈도우 라이브에 로그인 하지 않아도 이 허용토큰을 통해 웹 어플리케이션이 사용자의 로그인을 대신해 주게 됩니다.


반면 별도로 허용토큰을 웹 어플리케이션의 데이터베이스에 저장하지 않고 사용자가 직접 Windows Live Messenger 사이트로 부터 발급받은 뒤  웹 브라우저의 life time과 함께 관리하기로 한 경우(one time cookie)에는 브라우저가 닫혀지지 않는 한 로그인이 유지되지만 다음 번 사이트를 방문하게 될 경우에는 허용토큰이 남아 있지 않기 때문에 사용자는 다시 금 로그인 절차를 진행해야 합니다.

이와 같은 방식의 로그인을 어플리케이션 검증토큰을 통한 위임 로그인(Application Verifier Tokens for Delegated Authentication)이라고 합니다. 
 

지금 우리가 앞서 실행해본 방식은 어플리케이션 검증 토큰을 이용한 위임 로그인 방식을 이용한 것이라는 것. 이해 되시겠지요?

사이트와 사이트 사이 서로 연계되어 데이터를 교환하는 요구사항들이 늘고 있는 요즘 위임인증은 상당히 효과적이고 안전한 인증 방식이 됩니다.

위임 인증을 보다 간단히 설명을 하자면,

A 라고 하는 저장소(스카이드라이브/ 페이스북 / 트위터 등등)에 있는 나의 데이터를 B라고 하는 사이트에서 사용하고자 할 때 B 사이트에 A에서 사용되는 아이디와 패스워드를 우리가 넘겨준다면?
해킹의 소지도 있을 뿐만 아니라 왠지 모를 찝찝함이 남을 수 밖에 없죠.
 
[B 라고 하는(Importer)에게 Web Site(저장소)에서 데이터를 가지고 오기 위해 자신의 아이디와 패스워드를 전달하는 예]

하지만 이러한 방식을 그림에서 처럼 바꿔준다면,
 
[위임인증 토큰을 사용하여 Importer는 Web Site에 사용자의 정보를 요청한다]

사용자는 안전하게 Web Site에 저장된 데이터를 Importer에게 별도로 자신의 Credential 정보를 넘겨주지 않고도 사용할 수 있게 되는 것입니다.

지금 보시는 비디오 클립이 잘 설명해 주고 있습니다.
친구를 추가하기 위해서 Windows Live에 MySpace의 Credential 정보를 넘겨주지 않죠.
이것이 바로 위임인증을 사용한 예 입니다.

보다 자세한 위임인증(Delegated Web Auth) 에 대해 알고 싶으시면 소개해 드리는 링크를 꼭 한 번 읽어 보시라 권해 드립니다. - Understanding Windows Live Delegated Authentication

오늘은 윈도우 라이브 메신저 웹 툴킷이 사용하는 내부 인증 메커니즘에 대해 알아 보았습니다.
다음 글에서는 윈도우 라이브 툴 킷의 UI 컨트롤들을 이용하여 간단한 예제를 만들어 볼까 합니다.

윈도우 라이브 메신저 웹 툴킷 – 라이브 메신저의 모든 것을 웹에서

두 개의 포스팅을 통하여 간단히 라이브 메신저 웹 툴킷 UI 컨트롤들 중 Web Bar 를 웹 페이지에 호스팅 해 보았습니다.

이제는 보다 자세히 윈도우 라이브 메신저 웹 툴킷의 구성에 대해 살펴 봅니다.

Windows Live Messenger Web Toolkit의 구성  

1. HTML UI Control

앞서 설명한 바와 같이 윈도우 라이브 메신저 웹 툴킷은 모든 기능들이 모두 구현되어 있는 Web Bar 컨트롤에서부터 메신저를 구성하기 위해 요구되는 다양한 기능들을 모두 컨트롤화 하여 각 시나리오에 맞춰 사용할 수 있는 다양한 UI 컨트롤을 제공합니다. 이것들을 모두 통틀어 HTML UI 컨트롤 이라고 합니다.

2. Windows Live Messenger Library

윈도우 라이브 메신저 라이브러리는 자바스크립트로 구성되어 있는 스크립트 라이브러리로써 UI 는 별도 제공되지 않으며, 모든 기능들이 스크립트 객체와 객체들 간의 이벤트들을 통해 개발자들이 직접 메신저를 구현할 수 있도록 해 줍니다.

DHTML 기반이건(Ajax) Silverlight 건 Flash 이건 간에 JavaScript를 호스팅 할 수 있는 모든 곳에서 사용이 가능합니다. 앞서 소개한 HTML UI Control의 모든 기능들은 윈도우 라이브 메신저 라이브러리를 사용하고 있습니다.

그러므로 HTML UI Control의 모든 이벤트들과 객체모델들을 스크립트 라이브러리들과 공유할 수 있습니다.

3. Windows Live IM Control

제 블로그 옆에 보이는 웹 메신저 창이 바로 Windows Live IM Control 입니다.
메신저 창의 기능이 오직 특정 사용자와의 대화로 제한됨을 확인 하실 수 있습니다.
이 경우 메신저 창을 통해서는 저하고만 대화 하실 수 있죠.
온라인 상점 혹은 온라인 오픈 마켓 등에서 특정 판매자 와 웹 상에서 대화를 할 수 있도록 해 주는 기능 등을 제공해 줄 때 유용합니다. [구현 예제 참조 : EC 21 (온라인 B2B 사이트)]

4. Windows Live Presence API

단순히 특정 사용자의 온라인 유무를 나타내기 위해 제공되는 API 입니다. 요청에 따라 JSON Format 의 데이터 혹은 Image 형식(온라인/ 오프라인 아이콘)의 서비스가 제공됩니다.

이러한 4가지 라이브러리가 바로 Windows Live Messenger Web Toolkit 의 구성 요소들 입니다.

 
[Windows Live Messenger Web Toolkit의 구성]

다시 HTML UI Control 살피기

윈도우 라이브 메신저 웹 툴킷이 이런 기능들로 이루어 져 있구나… 라는 것을 대강 살폈으니 이제 다시 우리가 구현해 두었던 HTML UI Control 들 중 Web Bar로 되돌아 옵니다.
그리고 내부 구성 들을 하나씩 들쳐 보도록 하죠.

우리가 실행했었던 웹 프로젝트를 비주얼 스튜디오의 솔루션 탐색기를 통해 들여다 보면 다음과 같은 파일들이 보이실 겁니다.

각각의 파일들의 용도는 다음과 같습니다.(보이는 순서대로)

• Channel.html – 메신저 서버와의 통신을 위해 사용되는 스크립트가 담겨있는 파일입니다.
  Cross Domain scripting의 보안상의 문제를 우회할 수 있는 다양한 방법들이 있는데 그 중 내부적으로 iframe을 동적으로 만들어 호출하는 방식이 있습니다.
  Microsoft Web Messenger Library에서는 이 방식을 통하여 Cross Domain 문제를 해결하고 있습니다. 
  이 기법에 대해 보다 자세히 알고 싶으시다면 소개해 드리는 링크를 참조하시기 바랍니다.
  내용을 한번 정독해 보시는 것도 많은 도움이 될 것이라 생각합니다.
  [ The Architecture Journal - Secure Cross-Domain Communication in the Browser ]
  
• Default.aspx – Web Messenger Control UI 를 호스팅 하고 있는 페이지이죠. 각 파일들에 대한 설명을 마치고 다시 살펴 봅니다.
  
• Privacy.html – Login 창에서 Privacy 정책과 관련한 안내 문구가 담긴 페이지입니다. 서비스 시에는 정식 문구가 쓰여져야 하겠지만 현재로써는 별 내용 없는 Dummy 페이지에 불과합니다. (하지만 반드시 필요한 파일입니다!)
  
• RefreshMessengerToken.aspx – Windows Live ID Delegated(위임인증) 을 통하여 사용자의 인증 토큰과 메신저 사용을 위한 인증 토큰을 쿠키에 넣어 관리하기 위해 필요한 파일입니다. 별도로 토큰을 관리할 목적이 아니라면 그냥 사용해도 무방한 파일입니다. 이 부분 역시 좀 더 자세히 알아 볼 때 다시한번 살펴볼 파일입니다.
  
• web.config – 우리가 메신저를 호스팅 하기위해 필요한 Application ID와 Security Key에 대한 정보를 저장해 둔 환경설정 파일입니다.

통신을 위한 체널 파일, 인증 쿠키를 관리할 RefreshToken 파일과 Privacy 정보가 담긴 파일 이렇게 3개의 파일들이 준비되어 있으면 기본적으로 메신저 서비스를 호스팅 할 수 있는 기본적인 요구사항들을 갖췄다 생각하시면 됩니다.

앞으로 살펴보게 될 모든 컨트롤들 역시 위에서 설명 드리는 이 파일들이 기본적으로 준비되어 있다는 가정하에서 구현이 시작됩니다. 
[시나리오에 따른 각각의 16개의 HTML UI Control들]

위의 그림은 16개의 HTML Control들을 각각의 시나리오 별로 나누어 구분 지어놓은 그림입니다. 이것들을 표로 정리하자면 다음과 같습니다.

구분	컨트롤 이름	설명
Profile	Profile
Presence	Displan Name
	Display Picture
	Presence Status
	Personal Message
Contacts	Add Contact
	Contact List
	Contact Picker
	Application Contacts	특정 사용자에게 자신이 등록하지 않은 사용자에 대한 로그인 여부 상태를 알 수 있도록 합니다.(Invisible)
Chat	Conversation
	Converstation List
WebBar	Messenger Web Bar
	IF	특정 조건을 만족할 때 컨트롤을 보일 수 있도록 해 주는 Block (Invisible) – 예를 들어 로그인 했을 때 보일 것과 로그오프인 경우 각기 다른 UI를 보이고자 할 때 유용합니다.
	Else	위의 IF 컨트롤과 함께 사용되며 IF 조건에 만족하지 않은 조건 Block의 UI를 보이고자 할 때 사용됩니다. (Invisible)
	Messener Application	Windows Live Messenger UI 컨트롤들에 대한 초기화를 위해 반드시 필요한 컨트롤입니다. 다른 컨트롤들을 사용하기 위해서는 반드시 사전에 추가되어야 할 컨트롤입니다.
	Sign In

16개의 컨트롤들을 잘 조합해 주면 메신저 뿐만 아니라 간단히 Social 한 기능들을 여러분들의 웹 사이트에 추가해 줄 수 있습니다.

그러면 이제 앞서 실행했던 Default.aspx 파일의 HTML 코드를 살펴봅니다.

               1: <script
type="text/javascript" src="http://www.wlmessenger.net/api/3.0/loader.js"></script>

               2: <script
type="text/javascript">

               3:
              Microsoft.Live.Core.Loader.load(['messenger.ui', 'messenger.ui.styles.core']);

               4: </script>

페이지의 서두에는 다음과 같이 자바스크립트 라이브러리의 위치를 지정하고 Microsoft.Live.Core.Loader.load 메서드를 호출하는 코드를 보실 수 있습니다. 이것은 Windows Live Messenger Control UI에서 사용할 자바스크립트 라이브러리를 로딩하는 과정입니다.
기억하십니까? Windows Live Messenger Control UI들은 모두 윈도우 라이브 메신저 라이브러리의 기능들을 활용한다는 사실.

자 조금 더 내려오시면 다음과 같은 HTML 을 확인하실 수 있습니다.

이 태그가 제가 설명 드렸던 UI Control들 중 Messenger Application 컨트롤 태그 입니다.

               1:
              <
              msgr:app
            

               2:
              id
              ="appTag"
            

               3:
              application-verifier-token
              ="<%=
ApplicationVerifier %>"
            

               4:
              privacy-url
              ="Privacy.html"
            

               5:
              channel-url
              ="Channel.html"
            

               6:
              token-url
              ="RefreshMessengerToken.aspx"
              >
            

               7:
              </
              msgr:app
              >
            

이게 무슨 HTML이냐~ XML 아니냐? 하시는 분들 계시겠지요? 이것을 XHTML이라고 합니다. XHTML 이 머냐? 이건 따로 공부해 주시고..(그래서 뭐냐?)
모든 윈도우 라이브 메신저 컨트롤들은 이러한 XHTML 태그로 구성되어 있습니다.

그래서 반드시 이러한 태그들에 정의에 앞서 네임스페이스 정의가 선행되어야 합니다. (제가 설명을 빼먹었죠?)
HTML 정의에 다음과 같이 네임스페이스 정의가 반드시 추가되어 있어야 합니다.

               1:
              <
              html
              xmlns
              ="http://www.w3.org/1999/xhtml"
              xmlns:msgr
              ="http://messenger.live.com/2009/ui-tags"
              >
            

Messenger Application 컨트롤 태그의 어트리뷰트들을 보면 Application-verifier-token 과 privacy-url , channel-url 그리고 token-url 값들이 나란히 정의되어 있는 것을 볼 수 있습니다.

Application-verifer-token 값은 제가 첫 번째 글에서 설명했던 Azure Service Portal 에서 등록했던 Application 의 ID와 Security Key값을 바탕으로 hashing된 값으로 서비스의 유효성을 보장받기 위해 반드시 필요한 값 입니다. 이 값이 어떻게 생성되는지가 궁금하신 분들은 각 언어 폴더 별로 제공되는 소스들을 참조하시면 쉽게 이해하실 수 있습니다. ( Application ID + Timestamp tag 를 SHA256 알고리즘으로 hashing… )

privacy-url 과 channel-url은 이미 앞서 설명 드렸고,
우리가 흥미롭게 살펴봐야 할 것은 token-url 값에 지정된 파일입니다.

token-url 이 무엇이냐? 제가 앞서서도 다시 한번 살펴 보겠노라 말씀 드렸던 부분이 바로 여기입니다.
token 이란 현재 사용자가 로그인 했는지 여부를 확인해 주기 위한 일종의 티켓과 같습니다.
놀이 동산 들어가실 때 손목에 띠 채워 주는 것. 클럽 들어가실 때 손목에 큼지막한 도장 찍어 주는 것 뭐 이런 것들이 일종의 티켓 되겠지요.

아래 보시는 내용은 우리가 인증을 마치고 Default.aspx 로 돌아왔을 때의 Request Header의 내용입니다.

이 두 개의 값이 Coolkie에 저장되어 있기 때문에 우리가 Cross-page Navigation을 하더라도 Chat Session을 그대로 유지할 수 있게 되는 이유 입니다.
그렇다면 msgr-consent-token과 msgr-delegation-token은 각각 무슨 역할을 하고 있을까요?

하나의 글에서 너무 많은 내용을 다루면 지루하다라는 피드백을 받아서.
일단 여기서 끊고, 다음 차례에서는 윈도우 라이브 메신저 웹 툴 킷의 인증 방식에 대해서 설명을 하도록 하겠습니다.

간단한 2,3회로 설명이 끝날 줄 알았는데 해야 할 말이 점점 많아 집니다.

윈도우 라이브 메신저 웹 툴킷의 인증 방식에 대한 이해는 앞으로 윈도우 라이브 서비스들의 인증에 대한 이해에도 많은 도움을 주게 됩니다.

다음 글에 앞서 제가 예전에 포스팅 했었던 Making the Internet a Safer Place 를 읽어 주십사 권해 드립니다.

계속 관심 가져 주시길…

윈도우 라이브 메신저 웹 툴킷 – 라이브 메신저의 모든 것을 웹에서

첫 번째 글 에서는 Live Web Messenger 호스팅을 위한 기본적인 설정과 사이트 등록 과정을 설명 드렸습니다.

이번 글 에서는 이제 프로젝트를 생성하여 간단한 Live Web Messenger Web Bar를 호스팅 해 봅니다.

본 글의 예제에서는 Visual Studio 를 통해 진행됩니다만, 대부분의 과정이 JavaScript 를 통해 이루어 지므로 다른 언어를 사용하는 개발자들도 쉽게 적용하실 수 있습니다.

이제 본격적으로 Live Web Messenger 를 우리의 웹 어플리케이션에 호스팅해 봅시다.

지난 글에서 제가 예제 파일을 다운로드 하십사 말씀 드린 파일 가지고 계시죠? 없어요? [다운로드]

1. 소스 파일 준비하기

압축되어 있는 파일을 열어보시면 GettingStarted 폴더 아래에 총 7개의 언어 이름으로 된 폴더가 보입니다.
 

폴더 이름을 보시면 예상 하셨다시피 Windows Live Messenger Web Toolkit은 Microsoft 기반 기술들만을 위해 제공되는 것이 아닙니다.
어떤 웹 개발 언어건 가리지 않고 툴킷을 사용하실 수 있습니다.

각자 자신의 입맛에 맞는 폴더 내의 소스 파일들을 적절한 위치에 압축을 풀어 준비합니다.  저는 FirstWebToolkit 이라는 폴더를 만들어 이 곳에 소스 파일들을 풀어 놓았습니다.

2. 가상디렉토리 설정하기