Who are you?


이동범(Dongbum Lee)


Microsoft Regional Director


Microsoft MVP - VB.net


MHVB.net 시삽

Wanna talk with me?

Subscription

MSN 메신저를 통해 글이 갱신되면 알려드립니다.

Windows Live Alerts

Search

Navigation

Categories

.net (16) .NET Service (1) Ajax (1) asp.net (2) authentication (1) AxWebBrowser (1) Azure (2) basic (2) blog (3) browser (1) Canvas for OneNote (1) Cloud Computing (4) Code Canvas (1) das blog (1) dasBlog (2) Data Portability (1) DataGridView (1) Delegated Web Authentication (1) FabrikamShipping (1) Geneva Framework (1) Google (1) IDE (1) Identity (1) ie (1) iis (2) IIS7 (1) I'm a PC (1) Internet Information Server (1) javascript (1) jQuery (1) Live Framework (4) Live messenger (8) Live Service (6) Live Writer (0) mac (1) Microsoft (16) Microsoft Azure Service Platform (3) oAuth (2) Office (2) OneNote (1) OOXML (1) OpenID (1) PC (1) PHP (1) Silverlight (1) small basic (2) Team System (2) UX (1) VB (3) vb.net (4) Vista (1) visual studio (6) visual studio 2010 (2) Windows Azure (2) Windows Azure Service Platform (2) Windows Live (9) Windows Live ID (4) Windows Live Messenger (7) Windows Live Messenger Web Toolkit (7) windows7 (1) Winform (3) WinFX (1) WPF (2) 개발자 (1) 독점 (1) 라이브 메신저 (3) 라이브 아이디 (3) 마이크로소프트 애저 (2) 베이직 (1) 비주얼 스튜디오 (1) 성공사례 (1) 성산포 (1) 스몰베이직 (1) 아웃백 (1) 애저 (2) 웹서버 (1) 윈도우 라이브 (7) 윈도우 라이브 메신저 웹 툴킷 (6) 음악 (1) 일상 (9) 제네바 프레임워크 (1) 조용필 (1) 클라우드 (1) 클라우드 컴퓨팅 (1) 통합개발환경 (1)

On this page

Windows Live Messenger Web Toolkit – Part 5
Windows Live Messenger Web Toolkit – Part4
Windows Live Messenger Web Toolkit - Part3
Windows Live Messenger Web Toolkit - Part2
Windows Live Messenger Web Toolkit - Part1
Let’s join Live Services Hackathon

Archive

Blogroll

Notice

알림
본 블로그는 저의 개인적인 의견을 담고 있습니다.
제가 몸담고 있는 조직의 공식적인 의견과는 다를 수 있습니다.

RSS 2.0 | Atom 1.0 | CDF Send mail to the author(s) E-mail

BlogStats

Total Posts: 67
This Year: 2
This Month: 1
This Week: 1
Comments: 24

Sign In

# Wednesday, June 17, 2009

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

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

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

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

learn_sdk
[그림처럼 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 어떤 언어든 상관없이 구현이 가능합니다.

[VB.net 코드]
   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:     Protected ReadOnly Property ApplicationVerifier() As String
  12:         Get
  13:             Return wll.GetAppVerifier()
  14:         End Get
  15:     End Property
  16: End Class
[C# 코드]
   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: public partial class MyOnlineBuddies: System.Web.UI.Page
  10: {
  11:     private WindowsLiveLogin wll = new WindowsLiveLogin(true);    
  12:  
  13:     /// <summary>
  14:     /// Gets an application verifier.
  15:     /// </summary>
  16:     public string ApplicationVerifier
  17:     {
  18:         get
  19:         {            
  20:             return wll.GetAppVerifier();            
  21:         }
  22:     }
  23: }

Step 3. HTML 페이지 기본 설정

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

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

   1: <html xmlns="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:app 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>
   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:profile cid="$user"></msgr:profile>

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

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

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

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

 


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

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

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

   1: <msgr:sign-in>
   2: </msgr:sign-in>
   3: <msgr:if cid="$user" condition="online">
   4:     <msgr:profile cid="$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로 바꿔 줄 수 있다면?

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

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

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

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

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

   1: <body>
   2:     <msgr:app id="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:     <div id="layout" style="text-align: center; font-family: Tahoma, 맑은 고딕">
   7:         <table style="border-width: medium; width: 500px; border-style: solid;" align="center">
   8:             <tr align="center">
   9:                 <td>
  10:                     <!-- Show display picture -->
  11:                     <msgr:if cid="$user" condition="online">
  12:                         <msgr:profile cid="$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:             <tr align="left">
  21:                 <td>
  22:                     <div id="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와는 달리 onauthenticatedonsignedout 이라고 하는 부분이 추가 되었습니다.
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:                 case Microsoft.Live.Core.NotifyCollectionChangedAction.add:
  41:                     onlineContacts.splice(e.get_newStartingIndex(), 0, e.get_newItems());
  42:                     break;
  43:                 //삭제  
  44:                 case Microsoft.Live.Core.NotifyCollectionChangedAction.remove:
  45:                     onlineContacts.splice(e.get_oldStartingIndex(), e.get_oldItems().length);
  46:                     break;
  47:                 //재갱신  
  48:                 case Microsoft.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: }
인증에 성공하면 파라메터로 넘겨지는 e 변수에는 사용자의 Identity 객체가 전달됩니다.(AuthenticatedCompletedEventHandler 참조)
이 Identity 객체를 사용하여도 사용자 객체를 얻어 낼 수 있으나, 더욱 쉬운 방식으로 TagFactory 객체의 user 프로퍼티를 통해 본 예제에서는 메신저 친구들 목록을 얻어내기 위해 필요한 로그인 한 당사자 객체인 User 객체를 얻어 내고 있습니다.(User 객체 참조
이렇게 얻어낸 사용자 객체의 onlineContacts (온라인 사용자 리스트) 프로퍼티의 collectionChanged 이벤트에 onOnlineContactsChanged callback 함수를 지정해 주고 있습니다.

하루에도 몇 번씩 메신저에 로그인/ 로그오프를 빈번하게 하기 때문에 당장 로그인 했을 당시의 사용자 목록이 계속 유지될 수는 없습니다.
그렇기 때문에 메신저 친구들의 온라인, 오프라인 정보가 변경 될 때 마다 새롭게 보여줄 온라인 친구 목록을 재 구성해 주어야 합니다.

우리 소스의 appTag에 지정된 collectionChanged 이벤트의 콜백인 onOnlineContactsChanged 함수가 바로 온라인 친구 목록을 재구성 해 주는 기능을 담당하게 될 것 입니다.

그런데 난데없이 다음 코드에 있는 setInterval 선언은 뭘까요?
 
원래 정확하게 메신저 친구들의 온/오프라인 변경에 따른 온라인 친구목록 구성과 목록 디스플레이의 코드는(displayBuddies) 모두 collectionChanged 이벤트의 콜백함수인 onOnlineContactsChanged 내에서 수행 되야 합니다.
 
하지만 워낙 빈번하게 이벤트가 발생하기 때문에 목록을 디스플레이 하기 위한 코드를 실행하기에는 적합하지 않습니다. 그래서 콜백함수에서는 온라인 친구목록의 컬렉션인 배열요소(onlineContacts)에 대한 처리를 담당하는 기능을 수행하고 부득이 디스플레이 하는 로직은 setInterval 함수를 통해 매 5초마다 업데이트(디스플레이)를 해 주는 방식으로 구현되어 있습니다.
   1: ///온라인 사용자들에 대한 CollectionChanged 이벤트가 발생 시 호출됨
   2: ///onlineContacts 배열에 사용자 정보를 추가,삭제, 갱신함.
   3: function onOnlineContactsChanged(sender, e) {
   4:     switch (e.get_action()) {
   5:         //추가  
   6:         case Microsoft.Live.Core.NotifyCollectionChangedAction.add:
   7:             onlineContacts.splice(e.get_newStartingIndex(), 0, e.get_newItems());
   8:             break;
   9:         //삭제  
  10:         case Microsoft.Live.Core.NotifyCollectionChangedAction.remove:
  11:             onlineContacts.splice(e.get_oldStartingIndex(), e.get_oldItems().length);
  12:             break;
  13:         //재갱신  
  14:         case Microsoft.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: }
위의 코드는 온라인 친구 목록을 동적으로 재구성하는 로직이 구현된 collectionChanged 이벤트의 콜백인 onOnlineContactsChanged 함수입니다.
코드의 설명처럼 온라인 되는 친구, 오프라인 되는 친구, 초기에 재구성되는 경우에 따라 onlineContacts 로 선언된 외부의 배열 변수를 조작하는 코드임을 쉽게 확인할 수 있습니다.
 
다음으로 흥미롭게 살펴볼 코드는 동적으로 사용자 목록에 따라 메신저 웹 툴킷 UI를 구성하여 추가해 주는 로직이 담겨있는 addList 함수입니다.
   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:  }
이 코드를 주위 깊게 살펴야 할 이유는 일반적인 HTML 태그와 달리 우리가 사용하고 있는 메신저 웹 툴킷의 UI 들은 XHTML 구성요소를 사용하고 있기 때문에 동적 생성을 위해서는 생성기(Factory)를 거쳐야만 가능하기 때문입니다.
이 때문에 생성기의 사용법을 주의 깊게 살펴 봐야 합니다. 메신저 웹 툴킷의 UI에서 사용되는 태그 생성기는 Microsoft.Live.Messenger.UI.Tags.TagsFactory 입니다.

우리의 코드에서는 동적으로 <msgr:display-name> 태그와 <msgr:personal-message> 태그를 생성하고 있습니다. 또 흥미로운 것은 이 태그에서 사용하는 속성값들(attribute)을 지정하는 방식으로 JSON 데이터 표현 방식을 사용하고 있습니다.

마지막으로 로그 오프시에 발생하는 SignedOut 이벤트의 콜백 함수인 OnSignout 함수에서는 인증 성공 시에 설정했었던 타이머를 해제하고, 동적으로 추가된 사용자 목록 UI를 청소해 주는 기능을 가진 코드가 추가되어 있습니다.
   1: function OnSignout(sender, e) {
   2:     clearInterval(timerID);
   3:     clearlist();
   4: }
간단한 자바스크립트 코드 몇 줄과 HTML 태그를 통하여 간단히 나의 온라인 친구들 목록을 구성하는 예제를 구성해 보았습니다.

메신저 웹 툴킷은 재미있는 컨트롤들과 이들을 쉽게 연결시켜 줄 수 있는 라이브러리들을 지원하기 때문에 아이디어에 따라서는 얼마든지 훌륭한 기능들을 가진 어플리케이션들을 구현해 낼 수 있습니다.

반드시 데스크탑에 메신저가 설치되어 있지 않은 환경이라도 친구와 대화를 나누거나 친구에게 메시지를 전달 할 수 있으며, 메신저라는 강력한 커뮤니케이션 수단을 통해 웹 사이트를 보다 Socal 하게, 보다 많은 트래픽이 넘쳐나는 사이트로 만들 수 있습니다.
 
Social 한 사이트에서 사용자의 트래픽을 유발시킬 수 있는 수단으로는 수동적인 Feed 보다는 적극적인 사용자와 사용자간의 메시지가 더 큰 힘을 발휘할 수 있습니다.
참고로 능동적 메시지 전달이 가질 수 있는 이점을 생각하게 해 줄 수 있는 블로그 글이 있어 소개해 드립니다.(User acquisition: writing on a notice board vs. sending a postcard)
왜 우리가 이 Windows Live Web Messenger Toolkit 에 관심을 가져야 하는지에 대한 보다 현실적인 이유를 느끼게 되실 것이라 생각합니다.
 
간단히 소개 드리려 시작한 포스트가 다섯 번째에 와서야 일단락을 짓게 되는 것 같습니다.
그래도 아직 Javascript 라이브러리와 Presence/ IM Control 과 관련된 기능은 제대로 맛도 보여드리지 못했는데 말이죠.
 
일단 Windows Live Web Messenger Toolkit과 관련된 블로그 포스팅은 이것으로 마무리 짓겠습니다.
 
다음 번 글에서는 윈도우 라이브 서비스에 대한 글을 써 보려 합니다.
아직도 윈도우 라이브가 마치 Microsoft 사의 전유물인양, Microsoft의 플랫폼만을 위한 배타적인 서비스로 알고 계신 분들이 많은 듯 싶어 이러한 오해를 불식시키기 위해 윈도우 라이브 서비스 전반적인 소개와 앞으로의 방향에 대해 정리해 보도록 하겠습니다.

# Wednesday, June 10, 2009

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

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

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

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

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

로그인 버튼을 클릭하면 아래 보이는 창이 팝업 됩니다. 이 창에서 deleAuthLogin붉은 색으로 박스 쳐진 부분을 보시면,
“귀하께서 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) 이라고 합니다.
사용자는 단 한번의 허용을 마치면 그 뒤로는 별도로 윈도우 라이브에 로그인 하지 않아도 이 허용토큰을 통해 웹 어플리케이션이 사용자의 로그인을 대신해 주게 됩니다.
StoredConsentTokenAuth

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

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

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

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

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

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

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

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

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

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

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

# Tuesday, June 09, 2009

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

intro

두 개의 포스팅을 통하여 간단히 라이브 메신저 웹 툴킷 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 의 구성 요소들 입니다.

Architecture 
[Windows Live Messenger Web Toolkit의 구성]

다시 HTML UI Control 살피기

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

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

Source

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

  • 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개의 파일들이 준비되어 있으면 기본적으로 메신저 서비스를 호스팅 할 수 있는 기본적인 요구사항들을 갖췄다 생각하시면 됩니다.

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

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

구분

컨트롤 이름

설명

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

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의 내용입니다.

GET /FirstWebToolkit/Default.aspx HTTP/1.1
Accept: */*
Accept-Language: ko-KR
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; MS-RTC LM 8; Tablet PC 2.0; Zune 3.0; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 4.0.20506)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.wltoolkit.com
Pragma: no-cache
Cookie: msgr-consent-token=eact%3DB4D%252BMpQ64igwHH%252Fgxb6tQ8qViFQYj5Sox%252BZcAztw6hCXDomPpK3HFq2A5uOYNZBqsDj9BZS3NRDIEXCuFM7bUs6TwCe5BITYKig21KeexvKZQi1tbPVIrI1xqegMHl9oOF0V%252BQhA3yC4gwNknEFtWJf6fV9OnRAZyBgdRLwSU%252FpJlrgU5rT3SFQd5CkkV%252BXRVRmLQHCxarUl48DqfxNkRXtnf9oJUNwb%252BL%252FBZxbI97dGuyG%252BVhtwsVWCGFw5QcPqwCVaHhootaEwjsdvbMDiYTjiv9LM651ZleNgxfG2RBV2wtTdubOst2LqcfKQn%252BAZPqrHSNF2ccPdjbf3seN6Cdfmc4OG1Ny0U690Ndrd3fkTH2Cdm2E5syL3ypkVMfRG2ZJ58zWYOPFLG%252Fmjl7qiUuYzHzzBwPAehQ2X0UTkwZ7ywVM%252BAEodAnuzUlAWphLOwWVGJVzZ63Rg34CQulFbCDV1hc2CgXpukK3ubOVXrXad8MMYUdmYOum8nChgIZejNmZhQaVOeY%252Be2g58LacCLXVEfZEoYYfny42J%252BskjRLtaYQkMzZat%252BHmDs1W0ntynbUKH1gxT8KEon7F9ou0S7Qvx0xUU56zLgdgiISE9CF0E61VXUijvZgF3cjvu1e1w1K3ij72iikwoui5Rd34DzNpA%252BgrJXAil9qrfXQjWI1nmqQ9fQbFv%252BJRHloKSLPyFrgvEZbaFuZ8%252FBC47FLvGWCZlCO9bzKh4BqJxWUtdnwI5h2mHs%252FrJ8T3RZ0W7fZ79Jxqhqq6RC8s5zzGKc23UoEXR%252FtrsZHaUqLaNs9qFY9iF1B%252FBJcj6rE8yGDuUQn8pRnxN5IRMx%252F%252FRAacQNENwjjgKbaHk%252BxwoayrA%252FqrWh9SjS9JZYCU1z1r%252FkIFeIIhqG5d0izUsF9sbbFx%252BXwDL8Q2lsGnaMGfBeHylx2Q51%252B%252FframzH1pX%252BtwQffqmiLuTphIvv2bfQpsLqXJ7Hm3rpkxkIqzwWWQQlLgsv%252FG3ecZvmVoSBuP4%252FbcU%252BTWps19CQeks51V2k56uyXzoHBU7IMfpEwfu2nCTnYUbvXWhWEoo5qnCuzXaqJowcWRmQpfP2tjLHT0vG0EwflO5qLHGy0sB2Y6agu7lkxXqHeLIRvG5wq9ifTk%252BcjJNP%252B0FoDQTED3CeuX3LHnBZ1eM%252BUhQ7%252FL%252FKfEcThnelsRKosHHn0bb%252BtjGSA%252Fwfv%252FUI%252B7wFcULowsep58ijbtUooDz0N9CsVRTgcwC2E9yD0d3M6rADe4%253D; msgr-delegation-token=EwCoARAnAAAUWkziSC7RbDJKS1VkhugDegv7L0eAAOLW3dYlVfvVGleoVqojHl4s6F0u5CfDec3KyATZtM%2BBMtIbFiTcIZF7UFOlwRQKSqIP26Tx9YS6xRbXwbnhQmtxxrX3dpqy2NAajF8%2FIdmTJE2CVQaFidDhIMMHRIrulhmDWtOTYFw6bJxKfF9D6TSFoBDMIZvqJ5Xgg%2FJDRKSlA2YAAAj%2BOy4jki13iPgA1CK%2B0740%2FUleHLq%2FdyLKoQ4PgpGxRP%2Fft7QLEbpL8pM%2BoJQEdOfN%2FB%2BcmhKPafUwDk6nO4Qj4KPUvkbL1FHCOVJ4Yx8zjKPN58QEUTtdkIAkd%2Bi%2BIRhl0iJv6v5op2cg2Mb6BxgHuM1tRvaQ41inNt%2FzQlBCjP0gRsHK%2BH%2FGPgCIs%2BVzTspi6T3Nec425DdqvwchzIdz79wkCpnV5SW17lqdML129kma3EK3vnC%2FaLe0ww3i9wjz171tgwT%2Fowk1u%2FFdJWfnDv1nnMOBQ%2FmMqPE8ArjbtRJU3fMrz%2Blza6KGgcT0AFmIW64hR3pbVmYMq4zOfJnwt5MAAA%3D%3D

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

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

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

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

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

계속 관심 가져 주시길…

# Monday, June 01, 2009

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

logo_messenger

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

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

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

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

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

1. 소스 파일 준비하기

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

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

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

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

그리고 해당 폴더를 웹 서버에서 80 포트로 접근할 수 있도록 가상 디렉토리로 설정해 줍니다.(가상디렉토리 이름도 FirstWebToolkit 으로 설정)

decompress_webFolder 
[압축을 푼 소스들이 들어있는 폴더에 가상 디렉토리 설정]

3. 소스파일 열기

가상디렉토리로 설정된 소스들이 담겨 있는 폴더를 Visual Studio를 통해 오픈 한 예 입니다.
SourceinVS 
갈무리 한 화면은 Visual Studio 10 Beta 1 버전입니다. 개발 툴 버전 역시 Visual Studio 2008, 2005 어떤 버전이건 상관 없습니다.

각 파일들이 무슨 역할들을 담당하는지 일단 묻지 말고, 따지지도 말고 실행부터 해 보려 합니다. :-)

4. 환경설정 파일 수정
web.config 파일을 엽니다.

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="wll_appid" value="%%YOURAPPID%%"/>
    <add key="wll_secret" value="%%YOURAPPKEY%%"/>
    <add key="wll_consenturl" value="http://consent.messenger.services.live.com/"/>
  </appSettings>
  <system.web>
    <compilation debug="true" strict="false" explicit="true" />
    <authentication mode="Windows"/>
  </system.web>
</configuration>

지난 글에서 Azure Service Portal 사이트를 통해 등록한 사이트의 Application ID 와 Security Key 기억 나십니까?
기억이 안나요? [확인하러 가기] (아.. 친절하다…)

그림에서와 같이 wll_appid 항목에 Application ID 그리고 wll_secret 항목에 Security Key 값을 지정해 줍니다.

이렇게..
Config

5. 실행

모든 준비가 완료 되었습니다. 이제 실행 해 볼 차례 입니다.
무작정 성격 급한 분들 F5 키를 누르셨겠지만, 해당 어플리케이션을 실행하기 위해서는 반드시 도메인 명으로 접근해 줘야 합니다.
즉, 저의 경우에는 http://localhost/FirstWebToolkit/Default.aspx 가 아니라, http://www.wltoolkit.com/FirstWebToolkit/Default.aspx 가 되겠지요. (도메인 명 앞에서 등록해 준 것 기억나시죠?)

앞으로 쉬운 디버깅을 위한 팁!
솔루션 탐색기에서 오른쪽 마우스 클릭하시고, 속성 페이지에서 시작 옵션을 선택해 주시면 아래 그림과 같이 시작 URL을 설정하실 수 있습니다.
StartURL

설정을 마치셨으면 이제 F5 키를 눌러 실행해 봅니다.

축하합니다. 비록 내부 구조에 대해서는 파악하지 못했지만 웹 어플리케이션에서 훌륭히 작동하는 윈도우 라이브 메신저를 확인 하실 수 있습니다.
웹 브라우저 아래에 보이는 메신저 UI가 바로 Web Bar 컨트롤 이라고 합니다.

다음 글에서는 계속해서 컨트롤들의 특징과 작동 원리 등을 알아보도록 하겠습니다.

“참 쉽죠 잉~”  :-)

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

382814ed-fb00-41ab-926c-8b468c0cc794

이번 글을 시작으로 몇 차례에 나누어 Windows Live Messenger Web Toolkit (윈도우 라이브 메신저 웹 툴킷)에 대해 소개하고자 합니다.

“윈도우 라이브 메신저 웹 툴 킷” 이란 웹 어플리케이션 상에서 메신저가 제공하는 다양한 기능들을 사용할 수 있도록 지원해 주는 UI / Utility 라이브러리 입니다.

모든 메신저의 기능들이 이미 구비되어 있는 UI 라이브러리에서부터(Windows Live Messenger UI Controls) UI와 관련된 부분 모두 개발자가 직접 구현할 수 있도록 메신저 구현에 필요한 기능들을 UI 없는 자바스크립트 라이브러리(Windows Live Messenger Library) 까지 다양한 요구에 대응할 수 있는 기능들이 제공됩니다.

제 블로그 글에 앞서 궁금하다 싶은 분들은 일단 체험해 보시는 것도 좋겠군요. [체험해 보기]

MessengerinHotmail
[Hotmail 에 적용된 라이브 메신저]

우선 간단히 Messenger Web Bar를 구현 해 보는 것에서부터 시작해 보려 합니다.

주저리 주저리 이야기를 늘어 놓기에 앞서 Step by Step 으로 구현을 해 본 후에 내부적인 구조를 살펴 보도록 하죠.

1. Windows Live Messenger Web Toolkit Sample Download 하기 [다운로드]

2. Site 등록하기
Site 등록이 필요한 이유는 채팅을 위한 서비스를 도메인 별로 제공하도록 하여 불법적인 서비스 호스팅을 막기 위함입니다.
Site 등록은 http://lx.azure.microsoft.com 사이트를 통해 진행 하실 수 있습니다. 해당 사이트는 향 후 Windows Azure Service Platform을 사용하기 위해서라면 반드시 여러분들께서 알고 계셔야 할 사이트이기도 합니다.

현재는 우리의 Windows Live Messenger Web Toolit을 이용한 서비스를 등록하기 위한 목적으로 사용합니다.

등록 과정에 앞서 테스트를 위한 도메인 이름을 하나 생각해 둡니다. – 저의 경우에는 www.wltoolkit.com 이라는 이름으로 서비스 테스트 도메인 이름을 미리 생각해 두었습니다.

  • Azure Service Portal로 이동하기http://lx.azure.microsoft.com

    설마 아직도 Windows Live ID 계정을 가지고 계시지 않은 분들은 없으리라 믿습니다. :-) 로그인 해 주시고!

    첫 번째 사이트 방문이시라면 아래 그림과 같은 페이지가 보입니다.
    firstAzurePortal 
    유감스럽게도 아직까지 Korea / Korean 이 지원되고 있지 않습니다만, “I Agree” 클릭해 주세요.


    firstAzurePortal_2
    TOS 읽어 주시고, 계정이 성공적으로 생성되었다는 화면이 보이시면 '”Continue” 버튼 클릭해 줍니다.


    firstAzurePortal_3
    본 화면은 Windows Azure Service 중에서 Windows Live Framework 와 Windows Azure를 사용하고자 하는 개발자들에게 필요한 화면입니다.
    지금 당장 필요한 것은 아니니 “Next” 버튼을 클릭합니다.

    AzurePortal 
    지금까지 잘 설명을 따라 오셨다면 위와 같은 페이지를 보실 수 있습니다.
    기본적으로 서비스를 사용하실 준비가 완료 되었습니다.

    이어서 본격적으로 Live Web Messenger 를 호스팅 하기 위한 등록 작업을 시작해 봅니다.
  • 사이트 등록하기

    다들 도메인 이름 하나씩 생각해 두셨죠?

    ”New Project” 를 클릭하여 새로운 프로젝트를 만듭니다.
    makeProject1 


    다음 화면에서 맨 아래 Live Services Existing APIs 메뉴의 붉은 박스 부분은 클릭합니다.

    *앞으로 Live Service 를 설명하는 저의 글에서 이 등록 사이트를 자주 보게 될 것 입니다.
    makeProject2

    “Terms of Use” 확인 해 주시고 “I Accept” 클릭.
    makeProject3 

    아래 그림과 같이 Project Label 과 Description, Domain 과 Return URL을 입력해 줍니다.
    Domain 항목에는 앞서 말씀 드린 것처럼 생각해둔 도메인 이름을 입력하고, Return URL은 일단 아래와 같이 Domain 이름과 같이 http://www.도메인명.com/ 으로 입력해 줍니다.

    참고적으로 덧붙이면 Return URL의 쓰임은 Live Web Messenger를 통해 로그인 과정을 마친 사용자가 Redirect 될 URL을 의미 합니다.
    makeProject4 

    도메인 등록절차를 성공적으로 마치시면 아래 그림과 같이 ApplicationID와 SecurityKey가 발급됩니다.

    여기서 발급된 Application ID와 Security Key는 앞으로 호스팅하게 될 Live Web Messenger 서비스의 Identity를 위해 사용됩니다. 
    미리 적어 두셔도 좋고, 필요하실 때 이 사이트로 들어와 확인 하실 수도 있습니다.
     makeProject5 
여기서 질문 있는 개발자 있으시겠다.
난 Static IP도 아니고, 도메인 명도 없는데 여기다가 아무런 도메인이나 입력해도 되는 거야?

답 : 됩니다. 호스트파일 이용해 주시는 센스 필요하죠. :-)

수고하셨습니다.
여기까지가 우리가 사전에 준비해 두어야 할 부분의 완성입니다.

다음 글에서 Live Messenger 호스팅 작업 계속 이어갑니다.

# Tuesday, May 19, 2009
Tuesday, May 19, 2009 11:38:09 AM (Korea Standard Time, UTC+09:00) ( Live messenger | Live Service | Windows Live | Windows Live Messenger | Windows Live Messenger Web Toolkit )

This is a personal invite from James Senior to attend the Live Services Hackathon in San Francisco on May 27, 2009.
Bring your code and work with the Live Services engineers to add Instant Messaging, Friends lists and more to your website.

If you want to joining this event, check out this url http://hackathon.eventbrite.com

Enjoy Live Service! :-)