OpenAuth, Google GData API JavaScript とプライベートデータのクライアントサイドマッシュアップについて
なんかいろいろと書きたくなってきたので書きます。長文失礼。
AOL OpenAuth のように、iframe でメールアドレスを選択させて、その結果を親フレームに返すようにすべきだと思いました
上の続き - kazuhoのメモ置き場なるほど。クライアント側でのマッシュアップで Service Provider → Consumer の流れなら IFRAME + HTTP Referfer を使った方が軽いということですね。 OpenAuth の仕組みは全然追っていなかったので、 id:shinichitomita さんのエントリをもう一度読んで勉強します。まず、そこから把握しないと議論にもならなそうですね。
クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダイアリー(2007-12-07)
まずはじめにちょっとだけ細かいところを補足しておくと、AOL OpenAuthはもちろんIFRAME前提じゃなくてもいける。要はConsumerとして適切な相手にOpenAuthの認証トークンが渡ってくればよいのであって、それをリダイレクトで渡そうがIFRAMEで同意した後にJSONPで渡そうが構わない。その際、IFRAMEとJSONPで受け渡しする場合においては、HTTPのリファラをチェックして親フレームおよびJSONPリクエスト送信元がちゃんと意図しているAPI Consumerのサービスなのかどうかをチェックしている。これはブラウザのリファラを切るとエラーメッセージが出ることからもよくわかる。
あと確認しておきたいのが、IFRAMEから親フレームに直接データのレスポンスを返してる訳じゃなくって、IFRAME（あるいはリダイレクト先）画面はあくまで情報の提供に対する同意（consent）の画面であって、肝心のデータのやり取りはあくまでJSONPだったり（サーバサイドなら）通常のサーバ間のHTTP Webサービスリクエストで行われている、というところ。
ちなみにIFRAMEを使う方法だと、AOLにログインしていない場合にログインボックスがでてしまうので正直いただけない。かなりフィッシングまがいなので*1、できればリダイレクト経由で認証トークンを受け取らせた方がよいだろうし、その場合でもブラウザのみでのクロスドメインデータアクセスは可能だ*2。
プライベートデータのクライアントサイドマッシュアップが可能なAPIたち
せっかくだし、以前調べたことについて、ちょっと散らかっていたのでまとめてみる。今のところクライアントサイドのみで、しかもPublic Dataではなく、マッシュアップできるサービスというのは２種類しか知らない（Flashとか含めるともうちょっとあるのかしらん）。
AOL Web AIM & OpenAuth
AOL Web AIM APIはJavaScript でAIMのチャット機能にアクセスできる。トークンの生成にはOpenAuthというのを使っている。OAuthとまぎらわしいが、AOL独自の認証プロトコル。
とりあえずまずはシンプルな例。ただの友達リスト取得してくれるだけだけど、クライアントサイド（ブラウザ内）だけでクロスドメインでのプライベートデータ取得ができている。
http://dev.aol.com/gallery_files/getBL.html
iPhone用のカスタムチャットクライアント。これももちろんすべてクライアントサイドで、実際にメッセージ送信も出来る。
http://x.aim.com/ty/#_startPage
AIMのログインIDがあれば試すことができる。ちなみにとみたのAOL IDは shinichitomita ですが、わざわざこれ(OpenAuth)を試すために取得したので、そもそもあまり使ってませんが、友達リストが淋しい場合はどうぞお気軽にBuddyにリクエストしてください。
OpenAuth & Web AIM関連で昔書いた記事
http://d.hatena.ne.jp/shinichitomita/20070617/1182097708
http://d.hatena.ne.jp/shinichitomita/20070908/1189246411
http://d.hatena.ne.jp/shinichitomita/20070910/1189436347
Google GData API (JavaScript Client)
つぎにGoogle GData API JavaScript Clientの場合。これはAPIアクセスのためのトークンとしてGoogle Account Authentication(AuthSub)を使っている。
Google Account Authでは証明書を必要とするsecure tokenと必要としないnon-secure tokenの２種類あるけども、前者の利用ではGoogleに登録が必要で、後者はそうでないかわりに、同意の画面で常にユーザに対して黄色いボックスで警告が出る。なおこの場合のsecure, non-secureとは、リクエスト送信の際に署名をさせることによって、万一トークンの受け渡しの際にConsumer以外にトークンが渡るようなことがあっても不正利用は出来ないよ、という意味。
そして実は、Google Account AuthをJavaScriptで使う場合、secure tokenは使えない。
Some Google services may allow access only by web applications that are registered and using secure tokens. AuthSub for JavaScript is not supported for such services. To use secure tokens, you'll need to use the standard AuthSub interface (and you thus can't use the JavaScript client library for this purpose), and your organization must register an SSL certificate with Google and sign all requests for those data feeds.
http://code.google.com/apis/gdata/authsub-js.html
これはJavaScriptでクライアントサイドで署名することがやっぱりナンセンスだからだろう。サーバで署名させたら、あまりJavaScript Client Libraryにした意味がないということか。
例。Google 地図とカレンダーのマッシュアップ。カレンダーのプライベート予定に含まれる場所の情報から、予定の情報を地図にプロットする。これもすべてクライアントサイドのみ。
http://jupiterit.com/traffik/public/index.html
ちなみにもうちょっと内部の通信について解析してみた記事はこれ。かなりトリッキー。
http://d.hatena.ne.jp/shinichitomita/20071006/1191645993
クライアントサイドマッシュアップのユースケースについて
データを組み合わせるのであればサーバサイドでいろいろな演算を行いたいだろうと思うし、そこをあえて、可能性が限定されるクライアントサイドで行う必然性があるユーセージモデルが自分には見えません。
http://d.hatena.ne.jp/kazuhooku/20071207/1197028716
これは、ちょっとid:kazuhookuさんと意見が違って、かなりあるのではないかと思っている。悲しいかな具体的な例があまりでてこないので単なる主張だけど。
まずサーバサイドでできることとクライアントサイドでできることと比べたとき、あきらかにサーバサイドで出来ることの方が多いというのはもちろん同意するけれども、それほど致命的でなくなっているようなケースもあるように思う。
黎明期（？）のマッシュアップではクロスドメイン通信するには必ずサーバで（あるいはサーバプロキシ経由で）みたいな話もあったけど、JSONPがhackなりに市民権を得てきてからそれもちょっと変わった。まあそれでも長いことクライアントサイドでの通信は良識としてPublic & Read-Onlyのみであったのだけれども、上記の２つに見られるようにPrivate & Read/Writeなサービスでも頑張れば可能なことがわかってきた。
そういう感じでクライアントサイドとサーバサイドにおいて出来ることにそれほど境目がなくなってくると、ここで活きてくるのがやっぱりJavaScriptであることによるスケーラビリティ（普及可能性という意味で）の大きさなんではないかな、とおもう。作ったマッシュアップアプリケーションがPerl限定だったりJava限定だったりすれば、deployの可能性もそこに携わる人に限定される。Google Maps APIが鬼のように普及したのは、単に地図スクロールUIの斬新さ以上に、自サイトへの導入においてHTMLに簡単なスクリプトをコピペするだけで良かったためだろう。そこにおいて、バックエンドがPHPかJavaかASP.NETかそもそも静的HTMLかなんてのは全く関係なかったから。
で、肝心のユースケースなんだけど、無い知恵を絞り出すと、例えばtwitterがWebAIMみたいな機能を実装したとして、ブログの見出しをクリックしたら自動的にtwitterにポストするとかくらいなら、まあできそうだし、AIMでいいならきっと今すぐにでもできる。まあこれはなんとなくはてなスターに近い話で、あまり単体では面白くないかもしれないけど、普及したときに何かあるかもというレベルの話。
あとは、クライアントサイドマッシュアップなら、Firewall越えも出来る、というのは案外重要じゃないかなと思う。つまり、サイボウズのグループウェアがクライアントサイドマッシュアップ用のAPIを出したと仮定して、そこに入っている社内スケジュールをiGoogle内のウィジットとしてGoogleカレンダーのデータと同時に表示できたりする。まあこの辺になるともうちょっとstudyが必要な分野かもしれないけど、かなり革新的だと思う人もいるのではないかなあ。
