1月 08 2009

FriendConnect向けあしあとガジェット公開とコード解説

FriendIntroducerはFriendConnectを試すことに主眼を置いて作ったガジェットだったため、それほど実用的なものではありませんでした。そこで、本格的に使えるガジェットとして、MyBlogLogやgooあしあと、Yahooログール的ガジェットとしてFootprintsを作りました。

Footprintsとは?

Footprintsは、サイトメンバーの訪問を記録するガジェットです。百聞は一見にしかず、このブログの左ペイン一番下にあるガジェットをご覧ください。もしこのサイトのFriendConnectに登録していなければ、Joinしてみてください。ログインしていない場合はしてください。 Footprints1 ご想像通り、ログインした状態でブログを訪問すると、あしあととして訪問記録が残ります。ほかの人が見ると、どのくらい前に訪問したかが分かります。また、最近流行の(?)あしあとを消す機能も実装済みです。 ガジェットXMLはhttp://devlab.agektmr.com/OpenSocial/FriendConnect/Footprints.xmlになりますので、欲しい方はご自由にお持ちください。貼り方はこちらを参考にしてください。

コードと動作の解説

FriendConnectとはいえ、中身はただのOpenSocialガジェットです。OpenSocial本も発売間近、mixigooホームのOpenSocial対応も近いということで、今回はサンプルコード付きでガジェットの内容を解説してみたいと思います。

基本的な動作

まず、あしあとの記録方式ですが、FriendConnectは残念ながらmakeRequest未対応のため、外部サーバーのDBに保存、なんてことはできません。AppData(Persistent API)を使って保存しています。AppDataはガジェット+ユーザーの組み合わせごとに存在するのですが、残念ながらOWNERであるブログ自体のAppDataには保存できないことが判明しました。この辺りはPermissionが絡んでくるのですが、一般的なOpenSocialとは事情が異なるため、特殊な権限の割り振りになっていると思われます。 この問題を解決するために考えたのが、VIEWERごとに自分のAppData領域にデータを保存する、という技。OWNERの友達のAppDataをまとめて取得すれば、似たような状況が作れるはずです。今回はこの方式でうまく実現することができました。 つまり、1つのデータ領域に配列であしあとを記録して行くのではなく、メンバーごとに最終アクセス日時をあしあととして記録し、Persistent APIのnewFetchPeopleAppDataでメンバー全員分をまとめて取得しています。

コード解説

        init:function() {
          // データリクエストオブジェクトを生成
          var req = opensocial.newDataRequest();
          // 閲覧者(viewer)の情報を取得
          var params = {};
          params[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS] = [opensocial.Person.Field.PROFILE_URL];
          req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER, params), 'viewer');
          // メンバー(OWNERの友達)のAppDataをまとめて取得
          var idspec = opensocial.newIdSpec({'userId':opensocial.IdSpec.PersonId.OWNER,
                                             'groupId':opensocial.IdSpec.GroupId.FRIENDS});
          req.add(req.newFetchPersonAppDataRequest(idspec, 'footprint'), 'footprint');

          // 上記2つの取得リクエストをまとめて投げ、callback関数で受け取ります
          req.send(function(response) {
            if (!response.get('viewer').hadError()) {
              fp.viewer = response.get('viewer').getData();
            }
            if (response.get('footprint').hadError()) {
              fp.footprints = [];
            } else {
              var footprints = response.get('footprint').getData();
              var exist = false;
              // AppDataはユーザーごとに返ってきますので、ループで回します
              $.each(footprints, function(footprint) {
                // AppDataは文字列しか受け付けませんので、取得時にJSONオブジェクトに戻してやります
                var json = gadgets.util.unescapeString(this.footprint);
                var foot = gadgets.json.parse(json);
                if (fp.viewer !== null) {
                  // 閲覧者と一致した場合は上書き
                  if (foot.id == fp.viewer.getId()) {
                    exist = true;
                    foot.id = fp.viewer.getId();
                    foot.name = fp.viewer.getDisplayName(),
                    foot.thumbnail = fp.viewer.getField(opensocial.Person.Field.THUMBNAIL_URL),
                    foot.profile = fp.viewer.getField(opensocial.Person.Field.PROFILE_URL),
                    foot.timestamp = (new Date()).getTime();
                    // 新しいあしあとをAppDataに記録
                    fp.setFootprint(foot);
                  }
                }
                fp.footprints.unshift(foot);
              });
              if (!exist && fp.viewer !== null) {
                // 今まで一度もあしあとを記録したことがない人の場合、追加します
                var foot = {'id':         fp.viewer.getId(),
                            'name':       fp.viewer.getDisplayName(),
                            'thumbnail':  fp.viewer.getField(opensocial.Person.Field.THUMBNAIL_URL),
                            'profile':    fp.viewer.getField(opensocial.Person.Field.PROFILE_URL),
                            'timestamp':  (new Date()).getTime()};
                fp.footprints.unshift(foot);
                fp.setFootprint(foot);
              }
              // 時系列でソート
              fp.footprints.sort(function(a, b) {
                return b.timestamp - a.timestamp;
              });
              // レンダリングします
              fp.showFootprints();
            }
          });
        },

ユーザーごとにAppDataを保存する部分は下記のコードです。

        setFootprint:function(foot) {
          // あしあとのデータオブジェクトを文字列に変換
          var str = gadgets.json.stringify(foot);
          var req = opensocial.newDataRequest();
          // 閲覧者のAppDataに記録
          req.add(req.newUpdatePersonAppDataRequest(opensocial.IdSpec.PersonId.VIEWER, 'footprint', str));
          req.send();
        },

OpenSocial的に役立ちそうな部分のみ抜粋していますが、上記コードで基本的な動作を行っています。ソースコード全体を読みたい方はこちらから。

まとめ

FrienConnectの特殊な環境としては、前述のPermission問題。それからmakeRequestの問題が分かってきました。いずれもプライバシーの重要性に配慮した結果と思われます。 Permissionについては、一般的なSNS上のOpenSocialでは、VIEWER自身がガジェットをインストールしているかどうかで挙動が変わりますが、FriendConnectではOWNERが常に仮想人格であることから、そもそもその前提がなりたたないため、特殊な動きをしているようです。 makeRequestについては、技術的な問題は既に解決済みのはずですので、特殊なPermission下で取得されたプライバシーに関わるデータを外部サーバーに安易に保存されることを避ける狙いがあるのではないでしょうか? 何はともあれ、このガジェットを使うと、「ああ、ブログをコミュニティに変えるってこういうことなのか」と、(少しだけ)感じることができます。ぜひお試しください。

View Comments add to hatena hatena.comment (6) add to del.icio.us (0) add to livedoor.clip (1) add to Yahoo!Bookmark (0) Total: 7

4月 23 2008

Cajaとは何か

Published by Eiji under OpenSocial

OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。

クロスサイトスクリプティングとブログパーツ

gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか?

Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaScriptが実行できれば、そのセッション情報や閲覧履歴を盗むことができてしまいます。これをXSS(クロスサイトスクリプティング)と言います。

XSSが発生するのは、投稿フォームを使って、そのドメイン上のページにJavaScriptを埋め込み、実行できるケースが挙げられますが、ブログパーツが貼れること自体もJavaScriptが埋め込めるという意味では同じであり、まともに作られたサイトであれば、まずこういったことは出来ません。

とはいえ、実際にブログパーツを貼付けることができるブログは存在しますし、セキュリティの問題を回避しつつこれを実現するためのアプローチがいくつか存在します。

JavaScriptを貼付けるためのアプローチ

ドメインを分ける

ブログを表示するドメインをセッション情報等のクリティカルなCookieを保存していないものにしてしまいます。盗むものがなければ、泥棒が入ったところで何も困ることはありません。このアプローチをとっているものにはlivedoorブログが挙げられます。

安全性の確認できたJavaScriptのみ許可する

サービス提供者が安全なブログパーツのリストを作り、ブログ管理者がそこから選ぶ、というアプローチです。ブログパーツの選択肢が狭くなるためユーザーには好まれませんが、全く貼れないよりはよいはず。gooブログやはてなダイアリがこのアプローチをとっています。

iframeで表示する

iframe内に別ドメインで表示してしまえば、上記「ドメインを分ける」と同様に扱うことができます。このアプローチを取っているものにiGoogleが挙げられます。iGoogleはブログではありませんが、ブログパーツ=ガジェットと捉えれば同じ問題を扱っていると言えます。

JavaScriptの危険な部分を無力化する

サーバーがJavaScriptを出力する前に危険な部分を書き換え、無力化してしまいます。このアプローチをとっているブログがあるか知りませんが、やり方としては誰でも思いつくのではないでしょうか。ただ、これを実現するためには膨大な労力と知識が必要となります。これがオープンソースで存在しているとすれば、どんなに素晴らしいでしょう。そして、これを実現することができるのが今回紹介する、Cajaです。

Cajaで実現できること

Cajaはカハと読みます。CajaはGoogleのオープンソースプロジェクトの名前で、これを使うことで、同一ドメイン上のページに安全に外部のJavaScriptを貼付けることが可能になります。

Caja紹介(日本語訳)

開発に当たってCajaを使って防がれるべきとされた攻撃方法の一覧

どこでCajaを使うのか

CajaはOpenSocialコンテナ上での利用を想定して作られているようです。Caja紹介(日本語訳)の説明も、Shindigでアプリケーションを利用することが前提となっており、Cajaを使ってガジェットをインラインで表示した方がパフォーマンスが向上する旨が記載されています。

Cajaの形態

実はここがまだ調べきれていない部分なのですが、どうやらJavaによるサーバーサイドでのリライトと、JavaScriptのライブラリで構成されている、ぽいです。この辺はもう少し調べる必要がありそうです。

何か他に情報をお持ちの方がいらっしゃいましたらぜひ、教えてください。

View Comments add to hatena hatena.comment (3) add to del.icio.us (0) add to livedoor.clip (1) add to Yahoo!Bookmark (0) Total: 4