--- layout: old_post title: MySpaceでOpenSocialアプリケーション OpenIDクライアント ー (3) permalink: /tatsuya/show/421-myspace-opensocial-openid-3 ---

前回から引き続き、OpenIDの "関連付け" と OpenSocial の汎用データストレージについて

MySpaceでOpenSocialアプリケーション "OpenIDクライアント" ー (1)

MySpaceでOpenSocialアプリケーション "OpenIDクライアント" ー (2)

 

association(共有鍵の交換)

OpenIDのspecでは認証リクエスト前にOpenID認証局と共有鍵の交換を行うことが推奨されている。

参考:http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#associations

本来、鍵交換にはDiffie-Hellman鍵共有アルゴリズムを利用するべき、と思うけど今回DH鍵交換アルゴリズムを実装するのが目的ではないのでsettion_typeは一番単純な "no-encryption" で実装する。

なお "no-encryption" の場合SSL(https)で通信するべきとのこと("no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption.)

 

まずOpenID RPからOPへ association リクエストを投げる、前回のHTMLベース探索と同様に OpenSocial API の makeRequest で通信を行い、認証結果を受け取る。


openid.association = function(request_option, callback){
var self = this;
var params = {};
params.contentType = gadgets.io.ContentType.TEXT;

//パラメータをクエリーストリングとして付加しURLを組み立てる
var param = [];
param.push(["openid.ns","http://specs.openid.net/auth/2.0"]);
param.push(["openid.mode", "associate"]);
param.push(["openid.assoc_type", "HMAC-SHA1"]);
param.push(["openid.session_type", "no-encryption"]);
var url = this.makeURL(request_option.provider, param);

//association HTTPリクエスト
gadgets.io.makeRequest(url, function(result){
//association レスポンス解析
}, params);
}

送る方は簡単 session_type は "no-encryption"

 

共有鍵のキャッシュ -> OpenSocial汎用データストレージ

associationレスポンスを解析し有効期限(expire)が切れるまでキャッシュしておく。

今回はキャッシュのために OpenSocial API の汎用データストレージを利用する。このストレージ領域には key & value で任意の文字列を保存することが可能で、各アプリケーションそれぞれ別の保存領域となり、ユーザ毎にユニークとなるというデータストレージらしい。

opensocial.DataRequest クラスの newUpdatePersonAppDataRequest(ユーザID, key, value) メソッドを利用する。

http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newUpdatePersonAppDataRequest

下記のようにパラメータを解析し結果をJSON形式の文字列へ変換、それをvalue、OPエンドポイントURLをkeyとする。


gadgets.io.makeRequest(url, function(result){
var results = {};

//レスポンス結果を解析
var params = result.data.split("\n");
for(var i=0; i < params.length; i++){
if(params[i].search(":") > 0){
var param = params[i].match(/^([^:]*):(.*)/);
results[param[1]] = param[2];
}
}

//assoc_handle, mac_key, expires等必要な情報をJSON形式の文字列へ
var value = this.toJSON({
"assoc_type":results["assoc_type"],
"expires_in":results["expires_in"],
"mac_key":results["mac_key"],
"session_type":results["session_type"]
});

//汎用データストレージへ保存、keyはOPエンドポイントURL
var req = opensocial.newDataRequest();
var key = request_option.provider;
req.add(req.newUpdatePersonAppDataRequest(req.PersonId.VIEWER, key, value));
req.send(function(data){
callback(result, data);
});
}, params);

本来のDH鍵交換でやる場合は・・・HTTPリクエストをやって、データストレージへ期限切れるまでキャッシュという大枠は変わらない筈。

今回の gadgets.io.makeRequest API のようにOpenSocialコンテナ(myspace / orkut等)がプロキシとして働くHTTPリクエストの場合でも、DH鍵交換アルゴリズムなら盗聴の危険性は無いってことで良いのかな。あ、でもOpenSocialコンテナによる改竄の危険はあるのか。

まあ実装実験ということで。

 

以上

ちょっとしたJavaScriptのアプリケーションを作る時に、ちょっとしたデータ保存領域が欲しい事は結構あると思う。(占いアプリで占い履歴とか、占い選択肢とか)

その時サーバを自分で立ててWebAPIでデータストレージを用意してやるのは面倒、かなり面倒。

OpenSocial標準のAPIで汎用的なデータストレージが用意されていて、key & value ペアで任意の文字列を保存できるのは結構使い所ありそうだと思う。JSONにしてやれば構造化もできるわけだし。