썰렁한 엔지니어

URL과 관련된 부가 서비스

지난글에서 소개한 XRDS 파일을 OpenID가 위임을 하기 위해 사용하는 구조체로 설명하였습니다. 사실 XRDS 파일의 원래 용도는 그것보다 훨씬 다양합니다.

이야기를 하기에 앞서, 서비스와 그 서비스를 수행하기 위한 URL에 대한 수요는 상당히 많습니다. 예를 들어,

• RSS
  <link rel="alternate" type="application/rss+xml"
    title="..." href="..." />
• Atom
  <link rel="alternate" type="application/atom+xml"
   title="..." href="..." />
• FOAF
  <link rel="meta" type="application/rdf+xml"
    title="FOAF" href="..." />
• Open Search
  <link rel="search" type="application/opensearchdescription+xml"
    title="..." href="..." />
• 원격 블로깅 - MetaWeblog, Blogger API, MovableType API
  <link rel="EditURI" type="application/rsd+xml"
    title="RSD" href="..." />
• 원격 블로깅 - Atom
  <link rel="service.post" type="application/atom+xml"
   title="..." href="..." />

이런 URL들은 모두 HTML 소스의 head 태그 내에 기술되어 있습니다.

Accept 헤더?

마음 같아서는 http://coolengineer.com/ 과 관련된 서비스를 HTTP 관점에서 이렇게 접근하면 좋겠습니다만, 하나의 URL이 URL로서의 역할이 아닌 상황이 되기 때문에 표준을 좋아하시는 분들의 반발이 있을 수 있습니다.

GET / HTTP/1.1
Host: coolengineer.com
Accept: application/rdf+xml

또는

GET / HTTP/1.1
Host: coolengineer.com
Accept: application/opensearchdescription+xml

wget 으로 --header="Accept: ..." 옵션을 주어 테스트 해보실수 있겠지만, 아무 일도 일어나지 않습니다. ;)

부가 서비스 URL 검출기: XRDS

XRDS는 이런 종류의 검출을 일반화 시킬 수 있는 프레임웍으로 승격할 가능성이 있습니다. 즉, 서비스 URL 검출 방식을 "Accept: application/xrds+xml"로 통합시킬 수 있는 것입니다.

wget --header="Accept: xrds+xml" http://coolengineer.com/

요거하나만 허용하고, 내려 받게 되는 xrds 안에 서비스의 타입만 잘 정의해 줌으로써, 다른 서비스 검출로도 사용할 수 있다는 것이지요.

예를 들면, (아래는 제 생각일 뿐 사실이 아닙니다.)

<XRDS xmlns="xri://$xrd*($v*2.0)">
<XRD>
    <Service priority="0">
        <Type>http://a9.com/-/spec/opensearch/1.1/</Type>
        <URI>http://coolengineer.com/opensearch</URI>
    </Service>
    <Service priority="0">
        <Type>http://xmlns.com/foaf/0.1/</Type>
        <URI>http://coolengineer.com/foaf</URI>
    </Service>
</XRD>
</XRDS>

<!-- This is just my thought. DO NOT USE IN REAL ENVIRONMENTS. -->

이런 식으로 Service 태그의 나열이 되지 않을까 싶습니다.

며칠전 3/26에 제안된 XRDS Simple을 보며, 좀 더 많은 서비스가 XRDS에 맞게 나오는 것도 생각해 봅니다.

참고:

1. Really Simple Discovery - http://en.wikipedia.org/wiki/Really_Simple_Discovery
2. XRDS Service Discovery - http://wiki.openid.net/XRD-based_Service_Discovery
3. OAuth Discovery - http://wiki.oauth.net/Discovery
4. OAuth Extension - http://iiw.idcommons.net/index.php/OAuth_Extensions
   

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진

OpenID는 URL

가끔 이런 질문을 받습니다. 왜 OpenID에 도메인이 붙거나 슬래시같은 것이 들어가느냐, Email(ID@Domain 형식)을 오픈아이디로 쓸 수는 없느냐. 대개 이런 질문을 하는 것은 기존의 ID 체계의 연장에서 OpenID를 생각하기 때문입니다. 오픈아이디는 (주로) URL입니다. 물론 URL을 넘어 URI 그리고 XRI로 확장되어 있지만, 가장 대중적인 URL이라고 생각해보겠습니다. (참고로, URI와 XRI는 표준화 시작 주체가 다릅니다)

Identity URL과 URL 페이지의 내용

제 Identity URL은 http://coolengineer.com/ 입니다.  또한, 이것은 제 블로그 주소이므로, 이 페이지에는 저의 인증에 대한 정보와 제 블로그의 최근 글 (혹은 커버페이지)이 나와있습니다. 즉, 용도가 두가지로 쓰인다는 것입니다.

Identity 관련 내용

<link rel="openid.server" href="http://www.idtail.com/server" />
<link rel="openid.delegate" href="http://coolengineer.idtail.com/" />
<meta http-equiv="X-XRDS-Location" content="http://coolengineer.idtail.com/xrds" />

제 홈페이지 소스에는 위와 같은 태그가 삽입되어 있습니다. 저 뜻은 이 주소는 openid 인증용으로 사용되며, 그 서버는 뭐고, 해당 ID는 무엇이다라는 내용입니다. 위 link 태그는 1.x 용으로 만들어진 것이며, meta의 XRDS 위치는 2.0에서 추가된 것입니다. 물론 2.0 초안작업이 만들어지는 동안 이미, 1.1 라이브러리에도 구현이되어 들어가 있었습니다. XRDS 파일은 URL로 할 수 있는 서비스들의 목록을 기술한 것이며, 여기에는 OpenID 뿐아니라 하나의 URL로 할 수 있는 다양한 서비스가 기술될 수 있는 확장을 가지고 있습니다. 추후 Textcube에는 XRDS 파일에 들어갈 내용을 선택할 수 있는 확장을 넣을 생각에 있습니다. 그렇게 되면, 블로그 URL하나로 할 수 있는 일들이 많아 질 것으로 예상이 됩니다. (XRDS 편집기!)

준비 운동

이야기를 풀어가기 전에 wget을 디버거로 사용하겠습니다. wget에는 URL을 호출할 때, 여러가지 옵션을 주어 원하는 동작을 할 수가 있습니다. 사실 앞의 글의 예제 중 블로그 주소만 사용하여 이미지를 가져오는 것은 불가능한 것이었지만, 의미상 다음과 같은 명령을 수행하는 것이라 생각할 수 있습니다.

wget --header="Accept: image/png" http://coolengineer.com/

즉, "http://coolengineer.com/ 에 대해서 그림으로 취급할때 얻을 수 있는 것을 가져와보라"는 뜻이겠죠. 또한, 결과에 대해 HTTP 헤더파일을 보고 싶을 때는 다음과 같이 합니다.

wget -d http://coolengineer.com/

윈도우용 wget은 여기에서 쉽사리 구할 수 있습니다.

OpenID Relying Party(Consumer)의 내부 절차

내부절차에서 관심있는 것은 서버주소와 실제 ID에 대한 것입니다. 그러면 그 이하 길다란 페이지는 무엇에 써야할까요? 인증을 원하는 쪽에서는 아무짝에 쓸모없습니다. 따라서, 되도록 앞부분에 위치시켜놓는 것이 기계들을 위해 좋을 것입니다. 현재는 2.0까지 나온 상황이므로, 2.0을 기준으로 OpenID가 입력된다음 일어나는 초기이야기를 할까 합니다.

OpenID 1.1로 로그인할 수 있는 사이트에서는 다음과 같은 초기 절차가 일어납니다.

1. wget http://coolengineer.idtail.com/
2. index.html 파일 분석하여 openid.server link 태그를 찾음 openid.delegate가 있다면, 그 ID를 사용하여 진행함

OpenID 2.0의  XRDS 를 지원하는 사이트라면,

1. wget http://coolengineer.idtail.com/
2. index.html 파일을 분석하여 X-XRDS-Location meta 태그를 찾아 xrds의 위치를 얻음(http://coolengineer.idtail.com/xrds라 가정)
   
3. wget http://coolengineer.idtail.com/xrds
4. OpenID 관련 서비스를 찾아 서버 주소와 위임 정보를 찾아 진행함.

라고, 생각할 수 있습니다. 그러나, meta 태그의 의미를 잘 살펴보시면 알겠지만, http-equiv 입니다. 이것은 곧 HTTP 헤더에 있는 것을 그대로 기술하는데 그 의미가 있습니다. 즉,

1. wget -d http://coolengineer.idtail.com/
2. Header 출력중에 X-XRDS-Location 이라는 헤더가 있는지 찾아 xrds의 위치를 얻음.
3. wget http://coolengineer.idtail.com/xrds
4. OpenID 관련 서비스를 찾아 서버 주소와 위임 정보를 찾아 진행함.

이라는 것입니다. 실제로 OpenID서비스 제공자들은 저 헤더를 항상 넣습니다. 확인해보자면,

wget -d http://coolengineer.idtail.com/

HTTP request sent, awaiting response... HTTP/1.1 200 OK
Date: Sat, 22 Mar 2008 17:40:52 GMT
Set-Cookie: IDTAIL_SESSION=XXXXX; expires=Sat, 29 Mar 2008 17:40:52 GMT; path=/; domain=idtail.com
X-XRDS-Location: http://coolengineer.idtail.com/xrds
Content-Type: text/html

아니, 정말 그러하지 않습니까? 정작 관심있는 것은 http://coolengineer.idtail.com/ 을 통해서 얻을 수 있는 내용에 있는 것이 아니라 저 xrds 파일에 있습니다. 따라서, http://coolengineer.idtail.com/ 을 얻으려고 할 때, 저 xrds가 바로 날아 오면 얼마나 좋겠습니까?

그래서 이렇게 시도한다는 얘기 입니다. xrds의 Content-type은 "application/xrds+xml" 입니다.

1. wget --header="Accept: application/xrds+xml" http://coolengineer.idtail.com/
2. OpenID 관련 서비스를 찾아 서버 주소와 위임 정보를 찾아 진행함.

단계가 줄어 들었음을 알 수가 있습니다. 다시 예제를 통해서 살펴볼까요?

wget --header="Accept: application/xrds+xml" -d -O - http://coolengineer.idtail.com/

---request begin---
GET / HTTP/1.0
User-Agent: Wget/1.7
Host: coolengineer.idtail.com
Accept: */*
Connection: Keep-Alive
Accept: application/xrds+xml

---request end---
HTTP request sent, awaiting response... HTTP/1.1 200 OK
Date: Sat, 22 Mar 2008 17:57:35 GMT
Set-Cookie: IDTAIL_SESSION=XXXXXXXX; expires=Sat, 29 Mar 2008 17:57:35 GMT; path=/; domain=idtail.com
Content-Length: 505
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/xrds+xml

<?xml version="1.0" encoding="UTF-8" ?><xrds:XRDS
    xmlns:xrds="xri://$xrds"
    xmlns:openid="http://openid.net/xmlns/1.0"
    xmlns="xri://$xrd*($v*2.0)">
    <XRD>
    <Service priority="0">
        <Type>http://openid.net/signon/1.0</Type>
        <Type>http://openid.net/signon/1.1</Type>
        <Type>http://openid.net/sreg/1.0</Type>
        <URI>http://www.idtail.com/server</URI>
        <openid:Delegate>http://coolengineer.idtail.com/</openid:Delegate>
    </Service>
    </XRD>

즐거운 일이 일어나고 있습니다. 1편에서 안되던 일이었던, 하나의 URL에 여러 리소스의 역할이 충실히 일어나고 있습니다. 즉, 대부분에게는 제 mydtail 페이지가 나올듯한 것이, OpenID 로그인 진행에 필요한 의사 표현을 하게되니, 다른 내용이 전달되어 나오는 것이군요.

정말 장황한글 읽어주셔서 감사합니다...... 오늘은 맛있는거 드세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진

회사에서 오픈 소셜 세미나를 열게 되었습니다. 기술 발표 준비하느라 몇 주를 고생한 것을 생각하면, 금요일이 빨리 지나갔으면 하는 바램입니다. 물론, 이제 시작이기 때문에, 더할 나위없이 바쁜나날의 연속이겠지요.

열정이 많은 이창명씨에게 감사할 따름입니다. 세세한 것까지 개발하시느라 수고 많습니다. 난 뒤에서 코치만... ㅋㅋ.

발표자료는 http://hedgeplus.net/entry/idtail-opensocial 에서 보실 수 있습니다만, 아마 세미나 시작하는 2시 이후에 열릴 예정입니다.

대략의 제목은 다음과 같습니다. (추가되거나 변경될 수 있습니다)

• 오픈소셜이란?
• 서비스 제공자와 어플리케이션 제작자
• IDtail: Open API
• IDtail: Access Control
• OSoc: JavaScript API 1
• OSoc: JavaScript API 2
• OSoc: RESTful API
• OSoc: 사용자 행동 로그
• OSoc: 어플리케이션의 데이터 저장
• OSoc: 행동로그-데이터 저장의 한계
• OSoc: 어플리케이션 글로벌 데이터
• IDtail: OpenSocial 기능 구현 정도
• IDtail: OpenSocial 어플리케이션 시연

더불어, 발표 자료는 OperaShow를 이용하여 소개될 예정입니다. Textcube 스킨을 수정하면서 만들었는데, 잘만하면 쓸 만한 플러그인 하나 만들 수 있는 가능성을 보았습니다.

잠시 눈붙이고, 고고싱..!

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진

URL Fetch

http://coolengineer.com/ 이라는 주소를 브라우져에 입력하면, 흔히 웹페이지를 기대하기 쉽습니다. 좀 기술적인 표현을 써서,

Content-type: text/html

라는 데이터 스트림을 받게 되는 것이죠. 사실 브라우져 입장에서 보면 어떤 Content-type이 전송되어 올지 아무런 사전 정보없이 막연히 기다리는 것입니다. 오직 사람만이 웹페이지라고 기대하고 주소에 입력합니다. 브라우져의 마음가짐은

Accept: text/xml,application/xml,application/xhtml+xml,text/html,text/plain,image/png

뭐 이정도로 표현된다고나할까요? 즉, 사람에 의해 입력한 주소는 브라우져의 입장에서는 어떤 Content가 올지 기대하지도 않았던 뭔가를 받는 셈입니다.

URL 공유?

그런데 이런 코드는 어떨까요? /index.php 의 내용입니다.

<html>
<head>
<link type="text/css" href="/index.php" rel="stylesheet" />
<script type="text/javascript" src="/index.php" ></script>
</head>
<body>
<img type="image/png" src="/index.php" />
</body>
</html>

CSS도 JavaScript도 Image도 심지어 이 HTML도 모두 /index.php 를 통해 전달됩니다. 물론 이런 장난을 할 때는 Cache-control: no-cache 로 해야겠지요. 그러나 이 코드가 잘 동작하기 위해서는 브라우져가 /index.php를 가져올 때, 이렇게 해야합니다.

최초.
GET /index.php HTTP/1.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html,text/plain,image/png

다음.
GET /index.php HTTP/1.0
Accept: text/css

GET /index.php HTTP/1.0
Accept: text/javascript

GET /index.php HTTP/1.0
Accept: image/png

이렇게 Accept가 전송되어 오면 오죽 좋으랴마는, 실상은 그러하지 못하며. 따라서, 일반적인 웹브라우져로는 맨 위 코드에 해당하는 HTML이 존재할 수 없게 됩니다. 굳이 한다면, 순서에 따라 index.php의 내용을 내려주면 되겠지만, 가당치도 않겠죠.

맨 처음 화두를 꺼냈을 때와 두번째 Accept의 변경이 있을 수 있는 상황을 고려해본다면, 가장 큰 차이는, "특정 문맥 상에서의 URL 페치의 차이라 할 수 있을 것"입니다.

즉, 용도에 따라 URL을 가져오려한다면, 그 용도가 서버에 전달 될 수 있을 때, URL은 중복 될 수 있다는 뜻입니다. 즉, http://coolengineer.com/ 과 ftp://coolengineer.com/ 의 차이가 아닌 http://coolengineer.com/ 내에서의 용도 분화에 따라 다른 것을 수신할 수 있는 것을 의미합니다.

다음엔, 이 생각으로 좀 더 발전된 주제인 OpenID가 바라보는 URL에 대한 생각을 정리해보려합니다. 기대해주세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진

Yahoo에서 발급하는 OpenID가 아직은 Beta 수준입니다. Yahoo는 OpenID2.0을 기준으로 만들고 있죠.

혹시 Yahoo의 오픈아이디를 시험해 보실분들은, Textcube 1.6.x가 설치되고 OpenID가 활성화된 곳에 로그인해보시기 바랍니다. Textcube는 OpenID 2.0 스펙으로 발급된 아이디가 소비될 수 있는 발빠른 공간입니다.

2.0을 지원하는 Yahoo OpenID는 openid 쓰는 곳에 yahoo.com 만 쓰면 됩니다. 아직은 Attribute eXchange는 지원하지 않습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진