Google Friend Connect の two-legged OAuth とその使いどころを確認してみた

こんばんは。なかじまんです。なんか Google Wave の熱気がスゴイんですが、Google Friend Connect ネタでいきます。

はじめに Google Friend Connect (GFC) の two-legged OAuth を使って、ユーザのプロフィールを取得して表示してみました。スクリーンショットはこんな感じです。



そして、ソースコードはこんな感じです。いつもどおり Aptana Jaxer を使っています。JavaScript なのでクライアントサイドに見えるかもしれませんが、サーバサイドで動かしています。ややこしくてごめんなさい。

<script type="text/javascript" src="sha1.js" runat="server"></script>
<script type="text/javascript" src="oauth.js" runat="server"></script>
<script type="text/javascript" src="jquery.js" runat="both"></script>

リクエストの署名は Google Code の OAuth JavaScript ライブラリを使っています。表立って JavaScript ライブラリのリンクは存在しませんが、SVN や Google Group を探るとたどり着けます。

<script type="text/javascript" runat="server">
jQuery(function($) {

var action = 'http://www.google.com/friendconnect/api/people/@me/@self';

var accessor = {
consumerSecret: '{consumerSecret}'
};

var message = {
method: 'GET',
action: action,
parameters: {},
};

OAuth.setParameter(message, 'oauth_consumer_key', '*:03382920006806842951');
OAuth.setParameter(message, 'oauth_version', '1.0');
OAuth.setParameter(message, 'oauth_timestamp', OAuth.timestamp());
OAuth.setParameter(message, 'oauth_nonce', OAuth.nonce(6));
OAuth.setParameter(message, 'xoauth_requestor_id', '12976690996215323511');

OAuth.SignatureMethod.sign(message, accessor);

コンシューマキーとそのシークレットを使って、リクエストに署名しています。



↑コンシューマキーとシークレットは GFC サイトで入手できます。

var url = OAuth.addToURL(action, message.parameters);

var text, person;
try {
text = Jaxer.Web.get(url, { as: 'text' });
person = eval('(' + text + ')').entry;
} catch (e) {
throw new Error(''+e);
}

$('#person span').text(person.displayName);
$('#person img').attr('src', person.thumbnailUrl);
$('#person textarea').val(text);
});
</script>

署名したリクエストを発行して、該当ユーザのプロフィールを取得しています。そして、プロフィールを HTML として表示しています。

<p id="person">
<span></span><br />
<img /><br />
<textarea rows="10" cols="80"></textarea>
</p>

プロフィールを表示する HTML です。textarea 要素にレスポンスのテキストをそのまま表示しています。

GFC のドキュメントでは RESTful API 仕様どおり @me の部分に guid を指定できる と解説があるのですが、次のパターンを試してみたのですが、すべて 401 エラーとなってしまいます。あれれ。何か間違っていますでしょうか。ですので、今回は @me として xoauth_requestor_id でユーザ ID を指定しています。

people/12976690996215323511/@self
people/friendconnect.google.com:12976690996215323511/@self
people/friendconnect.google.com%3A12976690996215323511/@self

GFC の two-legged OAuth が使えることが確認できたので、次はその使いどころです。

GFC の Server-side Integration のデモとして、次のような The Chow Down というサイトとその ソースコード が公開されています。その中で two-legged OAuth を使っています。



two-legged OAuth の主な使いどころは、(あたり前ですが)ユーザが GFC にサインインしていないときです。The Chow Down は、サイト独自のユーザ登録による認証と GFC による認証を併用しています。

GFC にサインインしているときは、Cookie の fcauth トークン を使えば The Chow Down のすべてのリソースにアクセスできるので、このとき two-legged OAuth を使う絶対的な理由はありません。

サイト独自の認証でサインインしているとき、The Chow Down リソースにアクセスするために two-legged OAuth が必要になります。プロフィールなどのデータは手元に保存してあるので two-legged OAuth は必要ないのでは ... と疑問に思いましたが、GFC のドキュメントをよく読んでみると、取得したプロフィールなどのデータはキャッシュはしていいけれど、ユーザID 以外は永続的に保持してはならないとあります。

ですので、The Chow Down は、GFC と関連付くユーザのプロフィールを参照するとき、キャッシュを調べて、キャッシュに存在しないとき、two-legged OAuth でプロフィールを取得してキャッシュするようになっています。

じゃぁ逆にいうと Cookie の fcauth トークンは不要では... と感じてくるのですが、少なくとも GFC にサインインしないと、該当ユーザの ID が判別できません。また、The Chow Down は GFC にサインインしているとき、@viewer/@friends を使って GFC ネットワークの友達関係を持ち込んで、アプリケーション上でうまく活用しています。

The Chow Down の設計方針は
The Chow Down - Server-side integration walkthrough に解説があるので、GFC を自サイトに統合しようと考えているときは、まずはじめに一読するとよいと思います。