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) Cloud Computing (4) das blog (1) dasBlog (2) Data Portability (1) DataGridView (1) Delegated Web Authentication (1) FabrikamShipping (1) Geneva Framework (1) Google (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) 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 (5) visual studio 2010 (1) 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) 애저 (2) 웹서버 (1) 윈도우 라이브 (7) 윈도우 라이브 메신저 웹 툴킷 (6) 음악 (1) 일상 (9) 제네바 프레임워크 (1) 조용필 (1) 클라우드 (1) 클라우드 컴퓨팅 (1)

On this page

Windows Live Messenger Web Toolkit – Part 5
Identities from Live ID and Web SDK for 3rd party web sites - UUID and CID
Windows Live Messenger Web Toolkit – Part4
Making the Internet a Safer Place

Archive

Blogroll

Notice

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

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

BlogStats

Total Posts: 66
This Year: 1
This Month: 0
This Week: 0
Comments: 23

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의 플랫폼만을 위한 배타적인 서비스로 알고 계신 분들이 많은 듯 싶어 이러한 오해를 불식시키기 위해 윈도우 라이브 서비스 전반적인 소개와 앞으로의 방향에 대해 정리해 보도록 하겠습니다.

# Thursday, June 11, 2009
Thursday, June 11, 2009 10:44:11 AM (Korea Standard Time, UTC+09:00) ( Live Framework | Windows Live | Windows Live ID | 라이브 아이디 | 윈도우 라이브 )
  • UUID is a hash of PUID + ApplicationID.
    The purpose is to force 3rd 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.
# 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 컨트롤들을 이용하여 간단한 예제를 만들어 볼까 합니다.

# Thursday, February 12, 2009
Thursday, February 12, 2009 2:56:26 PM (Korea Standard Time, UTC+09:00) ( authentication | Data Portability | Delegated Web Authentication | oAuth | OpenID | Windows Azure Service Platform | Windows Live ID )

Windows Live Service team 의 Angus Logan 씨가 Safter Internet Day에 있었던 OpenID UX summit에서 느꼈던 Ineternet 을 보다 안전한 곳으로 만들기 위한 Microsoft의 솔루션에 대해 기술한 블로그를 소개 합니다.

Making the Internet a safer

Social Network에 대한 관심이 높아져가면서 이와 함께 인터넷 사이트 도처에 흩어져 있는 사용자의 연락처 정보들에 대한 관리가 커다란 관심거리가 되고 있습니다.  

이러한 정보들을 한 곳에 모을 수 있는 솔루션들도 많이 출현하고 있는데 그 중 대표적인 솔루션으로 Octazen(http://octazen.com/product_abi.php) 사의 Contacts Importer(Address Bokk Grabber)를 꼽을 수 있습니다.
* 물론 아쉽게도 국내 포털 사이트의 연락처 데이터를 가지고 오는 기능은 현재 제공하고 있지 않습니다. :-)

사용자가 어플리케이션에 자신의 아이디와 패스워드 정보를 입력하면 이 정보를 바탕으로 자동으로 해당 사이트의 연락처 정보를 가져오는 시나리오가 되겠는데요…..[테스트해보기]

image

문제는 여기서부터 시작 됩니다. 
솔루션을 개발한 업체를 못 믿어서 하는 이야기는 아닙니다만, 사용자만 알고 있어야 할 정보(아이디/패스워드)를 자신의 연락처 정보를 관리해 준다는 기능을 위해 울며 겨자 먹기로 솔루션 업체 (혹은 어플리케이션)에 알려 준다는 건 어딘가 보안상 불편한 느낌을 지울 수 없게 됩니다.
(그럴 리야 없겠습니다만, 악의적인 관리자에 의해 개인정보는 충분히 악용될 수 있는 소지가 있습니다.)

image
[내 아이디와 패스워드를 달라고???]

사용자의 정보는 사용자와 인증정보를 관리하는 곳만이 알고 있어야 하는 것이고, 그 이외의 사이트에서는 이에 대해 알 필요도, 관리도 해선 안 된다.
라는 지극히 당연하다라고 생각되지만 현실적으로 그래오지 못했었던 부분을 바로잡고자 하는 시도들이 인터넷 상의 인증프레임워크를 갖추는 일 입니다.

지난해 대형 온라인 경매사이트의 개인정보 유출 사건을 되돌아 보면 왜 인터넷상의 인증 프레임워크(서비스)가 필요한 것인지를 충분히 느끼실 수 있을 것입니다.

MicrosoftLiveID(Delegated Web Authentication)OpenID/oAuth 가 바로 이러한 문제들을 해결하기 위한 시도들 입니다.

Microsoft의 LiveID는 서비스는 Microsoft platform은 물론이고 Ruby, Phyton, Java, PHP, Perl 등과 같은 멀티 플랫폼을 지원하며 조만간 정식으로 OpenID까지 지원하는(참조 - Windows Live ID Commits to Support OpenID http://winliveid.spaces.live.com/blog/cns!AEE1BB0D86E23AAC!1745.entry) 가장 앞선 인터넷 기반의 인증 서비스를 제공합니다.
(Windows Azure Service Platform을 사용하기 위한 기본 인증 서비스이기도 합니다.)

image

인증을 위한 요청 흐름은 다음과 같이 정리될 수 있습니다.(여기서 데이터를 요청하는 어플리케이션을 – Application Provider(어플리케이션 프로바이더)/ 데이터를 제공하는 웹 사이트를 – Resource Provider(리소스 프로바이더)라고 합니다)

먼저 사용자는 특정 어플리케이션(어플리케이션 프로바이더)이 자신의 정보를 웹 사이트를 통해 얻어갈 수 있도록 허용하겠다고 허가를 하면, 인증프레임워크(서비스)는 어플리케이션(어플리케이션 프로바이더)에 인증토큰을 발급해 주고, 어플리케이션(어플리케이션 프로바이더)은 이 인증토큰을 사용하여 웹 사이트(리소스 프로바이더)에 사용자의 정보를 요청하는 순서가 됩니다.


[데이터를 가지고 올 Resource Provider 를 고르자]


[Windows LiveID 를 통한 인증]


[사용자는 Application Provider가 자신의 데이터에 접근할 수 있는 권한(Read,Write/ReadOnly/WriteOnly) 및 접근할 수 있는 기간을 지정함 – 인증토큰 발급]


[인증 토큰을 바탕으로 Application Provider가 가지고 온 Resource Provider의 데이터]

이 경우 실제 사용자의 아이디와 패스워드 정보는 인증 프레임워크(서비스)와 사용자 이외에는 전혀 알 필요도 없고, 관리할 필요도 없습니다.
인증 서비스를 제외한 어느 곳에도 사용자의 정보는 저장되지 않기 때문에 당연히 인터넷의 보안성 또한 높아질 수 밖에 없죠.

인터넷을 통한 네티즌들의 활동이 증가되어 감에 따라 온라인을 통해 생산되는 사용자 데이터는 단순히 연락처 정보를 넘어 사진을 포함한 멀티미디어 데이터, 메일, 어플리케이션 데이터 등 그 동안 일상 생활 속에서 우리가 PC환경에서 생산해 내던 데이터들과 그 양과 종류에서 차이가 없어지고 있습니다.

이렇게 될 수록 인터넷 여기저기 산재된 사용자의 데이터를 조직화 할 수 있는 기능 – Data Portability – 의 요구사항들이 늘어가게 됩니다. 이를 충족 시키기 위해 반드시 고려되어야 할 부분 역시 인증프레임워크(서비스)의 도입이 될 것입니다.

현재 국내의 주요 포털(N사, D사..등등..)들이 경쟁적으로 OpenAPI 를 발표하고 있음에도 불구하고 아쉽게도 아직까지 그러한 API들 중에서 사용자 중심적인 데이터를 제공하는 서비스가 없는 것도 사실은 내부적으로 이러한 인증 프레임워크 도입을 고려하고 있지 않음에 기인하고 있다고 이야기 해도 과언이 아닙니다. (최근에 D사에서는 OpenID 기반의 인증시스템 개발을 진행 중에 있다는 반가운 소식을 들었습니다.)

보다 안전한 인터넷 환경을 만들기 위한 노력. 이제는 선택이 아니라 필수인 시대가 도래했습니다.

자세한 Microsoft의 Data Portability에 관심이 있으신 분은 Windows Live Contacts API 를 살펴보시길 권장합니다.

다음 기회에는 Windows Azure Serive Platform 과 LiveID(인증프레임워크 서비스)와의 관계에 대해 정리해 보는 시간을 갖도록 하겠습니다.