OAuth WRAP という新しい OAuth の仕様が話題になってるので、ちょっとドキュメントを訳してみました。

全部翻訳するのは大変なので、利用シーンごとに分けて作られている "Profile" というのだけをそれぞれ訳しています。(WRAP は Web Resource Authorization Protocol の略らしい)

Facebook Connect を置き換えるものとしても注目されており、Javascript 単体のアプリケーションなんかも想定してあります。今回翻訳したドキュメントでは、まだ Javascript Profile は定義されていないのですが、MLに仕様書のドラフトが添付されていたので、そちらも同時に訳しています。

Smart.fm でも Javascript アプリ上での認証はオープン化の key なので、特に Javascript Profile に注目しています。

認可サーバとクライアントの二者間で認可を行う。いわゆる 2-legged。Refresh Token は利用しない。

Client Account and Password Profile (5.1)

This is the simplest Profile. The Client is provisioned with an account name and corresponding password by the Authorization Server. The Client presents the account name and password to the Access Token URL at the Authorization Server in exchange for an Access Token.

もっとも単純なプロファイル。認可サーバが個別のクライアントアプリケーションごとにアカウント名とパスワードを振り分け、クライアントは Access Token 取得時にそのアカウント名とパスワードを認可サーバに提示する。

Assertion Profile (5.2)

This profile enables a Client with a SAML or other assertion recognized by the Authorization Server. The Client presents the assertion to the Access Token URL at the Authorization Server in exchange for an Access Token. How the Client obtains the assertion is out of scope of OAuth WRAP.

クライアントと認可サーバの間で SAML などのアサーションを確立し、クライアントは Access Token 取得時にそのアサーションを認可サーバに提示する。どのようにアサーションを確立するかは OAuth WRAP のスコープ外。

User Delegation Profiles

クライアントがユーザの権限で認可サーバにアクセスする。いわゆる 3-legged。Refresh Token を利用する。

Username and Password Profile (5.3)

While the User may use a username and password to authenticate to the Authorization Server, it is undesirable for the Client to store the User's username and password. In this profile the User provides their username and password to an application (Client) they have installed on their device. The Client presents a Client Identifier, the username and password (credentials) to the Access Token URL at the Authorization Server in exchange for an Access Token and a Refresh Token.

When the Access Token expires, the Client presents the Refresh Token to the Refresh Token URL at the Authorization Server in exchange for a new Access Token.

ユーザは認可サーバへの認証にユーザ名とパスワードを使うが、ユーザ名とパスワードをクライアント側に保存するのは好ましく無い。このプロフィールではユーザが自身のユーザ名とパスワードを自身のデバイスにインストールされたアプリケーションに入力することを想定している。クライアントは Access Token & Refresh Token 取得時に Client Identifier とユーザ名、パスワードを認可サーバに提示する。

Access Token の有効期限が過ぎた時には、クライアントは Refresh Token を認可サーバに提示して、新しい Access Token を取得する。

Web App Profile (5.4)

It is undesirable for a User to provide their Authorization Server username and password to web applications. Additionally, the User may authenticate to the Authorization Server using other mechanisms then a username and password. In this profile, a web application (Client) has been provisioned with a Client Identifier and Client Secret and may have registered a Callback URL.

The Client initiates the protocol by redirecting the User to the User Authorization URL at the Authorization Server passing the Client Identifier and the Callback URL. The Authorization Server authenticates the User, confirms the User would like to authorize the Client to access the Protected Resource, and generates a Verification Code. The Authorization Server then redirects the User to the Callback URL at the Protected Resource passing along the Verification Code.

The Client then presents the Client Identifier, Client Secret, Callback URL and Verification code (credentials) to the Access Token URL at the Authorization Server for an Access Token and a Refresh Token.

認可サーバのユーザ名とパスワードをWeb アプリケーションに提示するのは好ましく無い。またユーザはユーザ名とパスワード以外の方法で認可サーバへの認証を行う可能性もある。よってこのプロフィールではクライアントはあらかじめ Client Identifier と Client Secret を取得する。その時同時に Callback URL を登録することもある。

認可開始時に、クライアントはユーザを認可サーバにリダイレクトさせる。このとき Client Identifier と Callback URL をパラメータとして渡す。認可サーバはユーザの認証を行い、ユーザの同意を得て Verification Code を発行する。その後認可サーバはユーザを Callback URL にリダイレクトさせる。このとき Verification Code がパラメータとして付与される。

クライアントは Access Token & Refresh Token 取得時に Client Identifier、Client Secret、Callback URL、Verification code を認可サーバに提示する。

Rich App Profile (5.5)

This profile is suitable when the Client is an application the User has installed on their device and a web browser is available, but it is undesirable for the User to provide their username and password to an application, or the user may not be using a username and password to authenticate to the Authorization Server.

The Client initiates the protocol by directing the User's browser to the Authorization URL at the Authorization Server passing the Client Identifier and potentially a Callback URL. The Authorization Server authenticates the User, confirms the User would like to authorize the Client to access the Protected Resource, and generates a Verification Code. The Verification Code may be communicated back to the Client in a number of ways

(A) the Authorization Server presents the Verification Code to the User, who is instructed to enter the Verification Code directly in the Client; the Client reads the Verification Code from the title of the web page presented by the Authorization Server

(B) the Authorization Server redirects the User to the Callback URL that presents Client specific language for the User to enter the Verification Code into the Client;

(C) the Client has registered a custom scheme and the Authorization Server redirects the browser to the custom scheme that causes the User's browser to load the Client application with the Verification Code as a parameter.

The Client then presents the Client Identifier, Callback URL (if provided) and Verification code (credentials) to the Access Token URL at the Authorization Server for an Access Token and a Refresh Token.

このプロフィールでは、クライアントはユーザのデバイスにインストールされているアプリケーションであり、かつ Web ブラウザが利用可能な状況を想定している。もちろんユーザがユーザ名とパスワードをアプリケーションに渡すのは好ましく無い。またユーザはユーザ名＆パスワード以外の方法で認証を行っている可能性もある。

クライアントはまず Web ブラウザを用いてユーザを認可サーバにリダイレクトさせる。このとき Client Identifier と Callback URL をパラメータとして渡す。(Callback URL は任意) 認可サーバはユーザの同意のもと Verification Code を発行する。Verification Code は以下のような方法でクライアントに渡される。

A) ユーザに Verification Code を提示して、ユーザがその Code をクライアントに入力する。もしくはクライアントが Web ページのタイトルから Verification Code を読み取る。

B) 認可サーバがユーザを Callback URL にリダイレクトさせる。ユーザはリダイレクト先 (おそらくクライアント側で用意した Web ページ) で Verification Code の入力を求められる。

C) クライアントは認可サーバに特別なスキーマを登録し、認可サーバはブラウザをそのスキーマにリダイレクトさせる。このスキーマへのリダイレクトにより、クライアントアプリケーションが起動され、パラメータとして Verification Code が渡される。

クライアントは Access Token & Refresh Token 取得時に Client Identifier、(もしあれば) Callback URL、Verification code を認可サーバに提示する。

Client App Profile

This profile is a suitable when the Client is an application that lives purely on the user's client - for example, on a desktop, or in JavaScript.

Because the entire source code for the Client is downloaded to the User's desktop or browser, it is not possible to protect the Client Secret. This profile allows for authorization while taking those security considerations into account. Because there is no Client Secret to ensure authenticity, both the Client and the Authorization Server should take some extra precautions when using this profile. Specifically, it should only be used when the risk of exposing the Access Token in a JavaScript environment is acceptable. To help mitigate this risk, it is strongly RECOMENDED that the Access Token have an expiration time on the order of a few hours.

If the Client wishes to obtain an Access Token with a much longer expiration time, they should make use of the "Client Refreshes Access Token" method within the Web App Profile.

このプロフィールではクライアントがデスクトップアプリや Javascript アプリなど、完全にクライアントサイドにある状況を想定している。

ソースコードは完全にクライアント上にダウンロードされるので、Client Secret を保護する方法は無い。そのためこのプロフィールではこれらのセキュリティ上の問題が考慮されている。このプロフィールを利用する際は、Client Secret を利用しない代わりに、クライアントと認可サーバ両サイドでなんらかの対策を行うおくべきである。特に Javascript アプリで利用する場合は、Access Token の漏洩が許容される場合にのみこのプロフィールが利用可能である。Access Token 漏洩リスクを軽減するため、Access Token は数時間程度で無効化することが望ましい。

クライアントが有効期限より長い間アクセス権を必要とする場合は、Web App Profile で定義された "Client Refreshes Access Token" のフローを利用するべきである。

子供達の保育園を変えたく無かったので、前の家からは車で15分ほどの近場です。

たまプラーザ駅のまわりを囲んで、「たまプラーザテラス」というのがあるのですが、ここがなかなかおしゃれでお気に入りです。

クリスマスにはサンタクロースも来てました。

「サンタさんはみんなが寝てから来るんだよ」と教え込まれていた息子は、起きてる時に来ていたサンタさんに驚愕していました（笑

しょうがなく、世の中には「プレゼントをくれるサンタさん」と「写真撮ってくれるだけのサンタさん」がいることにして、その場は解決しました。

インストール自体は簡単だけど、実際に Emulator を立ち上げるまでに少しハマり、Android で /etc/hosts をいじったりするところまではかなりハマったので、忘れないうちにメモメモ。

Download & Install Android SDK

Android SDK | Android Developers から、MacOSX 用の SDK をダウンロード。ダウンロードされたディレクトリごと適当な場所に配置して、SDK_ROOT/tools に PATH を通しておく。

Install Android SDK Components

次に Adding SDK Components | Android Developers にある通り、SDK Componets とかいうのをインストールする。

まずは以下のコマンドで Android SDK and AVD Manager を立ち上げる。（たぶん AVD は Android Virtual Device の略）

android

どうも僕の環境では HTTPS 経由だと失敗するので、Settings から HTTP を使うように設定。

ちょっと時間がかかるけど、Available Packages からとりあえず全パッケージをインストールしておく。僕の環境でインストールされたパッケージ一覧はこちら。

これで Emulator をセットアップする為の Target がセットアップされるみたい。

Setup Android Virtual Devices

Emulator 用に Android Virtual Device (AVD) を作成する。Emulator 起動時には毎回どの AVD を使うか指定する必要がある。

既に起動している Android SDK and AVD Manager の Virtual Devices -> New から、適宜自分にあったバージョンの Android OS を Target にして AVD を作成できる。Audio Recoding などの機種別の付加機能は、Hardware として追加できる。

Launch Android Emulator

自分で作った TARGET_NAME を指定して emulator コマンドで以下のように Android Emulator を起動する。Target に指定した Android OS のバージョンによって、見た目は違う。見た目でしか判断してないけど、Google Developer Day に配布されてた HTC のやつは Android 1.6 みたい。

Install Applications to Emulator

Android アプリ（.apk ファイル）を指定して、以下のようにアプリケーションをインストールできる。

adb install YOUR_APP.apk

Eclipse から直接 build して Emulator で起動する場合は、Installing and Updating ADT (for Eclipse) | Android Developers を参考に。一応 Eclipse からも使えるようにセットアップしたけど、個人的に Eclipse 派ではないので、ここでは割愛。

Edit /etc/hosts for Android Emulator

Android Emulator は、Emulator が走ってるマシンの /etc/hosts を無視する（/etc/resolve.conf しか見ない）ので、Android Emulator 自体が持ってる /etc/hosts ファイルを編集する必要がある。Android に最初から入ってる Dev Tools にも Terminal はあるけど、cat くらいしか使えないので、adb コマンドでホストマシンで編集した /etc/hosts ファイルを push してやる必要がある。

まずは remount。
これをしないと "failed to copy '~/Desktop/hosts' to '/system/etc/hosts': Read-only file system" というエラーがでる。。

adb remount

Emulator の既存の /etc/hosts を取ってくる。

adb pull /system/etc/hosts ~/Desktop/

適当に編集したら push。

adb push ~/Desktop/hosts /system/etc

push されたファイルを確認するには以下のように adb shell で Emulator 内の shell に入り、cat する。（less とか vi とかは入ってない）

adb shell
# cat /system/etc/hosts

「アンパンマン体操おどって」というと、iPhone で YouTube を立ち上げて、履歴からアンパンマン体操を選んで曲に合わせて踊ってくれます。2歳の娘と一緒に。

こちかめ、ゴーオンジャー、アンパンマン、そして何故か大塚愛がお気に入りで、「関連動画」から次々に気に入ったのを再生していくので、YouTube の履歴は常にそれらでいっぱいです。

たまに本人 or 妹が履歴を消してしまうらしく、そういう時には「こちかめ探して〜」とか言ってくるのですが。

また「写真撮らせて」とかいうと、iPhoneを持ってきて、うまいことカメラ使って逆に写真撮ってくれます。いつもピント合ってないけど。

僕や嫁がソファーでMacBook触ってると、Apple Remote持ってきて、見事に邪魔してくれます。iPhotoの写真やiTunesの曲も、Apple Remoteでちゃんと選んでます。「邪魔しないで」というと、「じゃあおふとんの部屋いき〜」と言われる始末。。。

DVDとか借りてくると、MacBookをTVにつないで、DVD入れて勝手に再生してるし。

末恐ろしいヤツですが、ちゃんと電源切れたら充電器持ってきて充電してたり、寝る前は iPhone を充電してくれたりするあたり、なかなか役に立ってます（笑

さて、どのタイミングで息子専用の Mac を買ってやろうかなぁ〜？

Google / Yahoo! Inc. の Contact API、正直友達の Email アドレスとかもらっても、スパムまがいの招待状送るくらいでどうせみんな登録しないんじゃない？本当は Facebook Connect みたいに「友達をインポートする」とかの方がやりたいのに。

G も Y! も OP になっていて、Smart.fm 内には各社数万単位でその OpenID を使っているユーザがいるので、Friend リストを OpenID で受け取れれば、Facebook Connect や Twitter なんかより遥かに高い確率で友達が見つかる、はず。

そして Email じゃなければ、Y! Japan さんも対応しやすい、かも？

OpenSocial Container の User ID が OpenID だったらいいのに

これも一つ目とほぼ同じ。mixi ID なんて送ってきて、僕らにどうしろと言うのさ！(まぁほとんどの mixi OpenID には mixi ID 含まれてるけど)

ってことで、OpenSocial Container も、OP やってるなら ID を OpenID にしちゃえばいいよね。

mixi OpenID で OAuth Hybrid 対応して、発行された Access Token で OpenSocial の Activity API とか叩けるようになれば、国内では Facebook Connect に負けるわけ無い。

って、mixi と MySpace 以外にどこがあるのか分からんけど。

OP / SP が iPhone 対応してくれればいいのに

OP が iPhone 対応してないから、自分とこのサイトが iPhone 対応しても、結局ログインはしにくいまま。どうせ2-3ページ対応すればいいだけだし、iPhone 対応してくれればいいのになぁ〜。

と、idcon でちょうどタイムリーな話題もあったので、いろいろ言ってみた。

しかし、僕が2日で最高レベルのリストをクリアできるのだから、レベル的にはちょっと簡単すぎるのかも。

やっぱもうちょっと専門的なのを出してかないと、ダメかな。

僕には絶対パーフェクト出せないだろうけどw

mixiアプリ公開から約1ヶ月、本日ようやくSmart.fmの公式mixiアプリ「英単語たたき」をリリースしました。

英単語たたきは、もぐらたたき形式で出題される日本語に合った英単語をハンマーで叩いて行くアプリです。

出題されるリストは初級〜上級まで全18リストで、それぞれのリストに設定された最低スコアを超えると、より高レベルのリストをプレイできるようになります。僕の英語力だと上級でパーフェクトを出すのは至難の業ですが、20回くらい同じリストをプレイして、さっきようやくすべてのリストをアンロックできました！現在マイミクランキングトップです、イェイ！！

両親の隠居先は、常陸太田という水戸よりちょっと北よりの街で、なんとものどかな場所でした。関東って本当に平野なのだなと思い知らされる程のだだっ広さ。

夜には天の川まで見えるし、まさしく「田舎」。

家は築100年以上の古民家で、さすがに床はガタが来てて張り替えたようですが、囲炉裏も土間もあります。

しかし、田んぼ４面に畑２つ付いた家が年間25万ってすごいよね。両親は畑１つで手一杯のようですが。

Rails アプリのエラー通知プラグインでは ExceptionNotification などがメジャーですが、それよりはるかに賢いプラグインを見つけたので紹介します。その名も「Hoptoad（ヒキガエル ）」。

正確には単なるプラグインではなく、エラー通知用プラグイン＋エラー管理Webアプリの組み合わせが「Hoptoad」です。

使い方は至って簡単。

script/plugin install git://github.com/thoughtbot/hoptoad_notifier.git

HoptoadNotifier.configure do |config|
  config.api_key = 'your_api_key_here'
end

class ApplicationController < ActionController::Base
  include HoptoadNotifier::Catcher
  :
end

rake hoptoad:test

あとは、エラーが発生したら Hoptoad サイトにエラー情報が蓄積されます。有料プランでは、backtrace の各行が github の特定のコミットにリンクされていたり、Lighthouse との連携も行えるようです。

無料プランでも、Hoptoad サイト内で backtrace の確認や Unresolved / Resolved の管理などは行えるので、ExceptionNotification でメール受け取るだけより断然イィ！

Twitterにブログの更新情報を通知する方法 - IDEA*IDEA なんて記事を見つけたので、タイトルかぶせてみるw

おそらく30分〜数時間おきに登録されたブログの RSS にアクセスしてる TwitterFeed よりは、更新 Ping 受け取った時だけ RSS 見に行く Twitbackr の方が、きっと速いよ。

ブログの使い方になれてる人なら、きっと twitbackr の twitter ログインボタンをクリックすれば twitbackr の使い方もすぐ分かる、はず。

さっそく使い方をレポートしてくれてる人がいるので、使い方はこちらを参考に。

Twitbacker からの変更点としては、

1. Twitbackr 上で Twitter のパスワードを入力する代わりに、Twitter に移動して「Allow」するように変わった。（OAuth）
2. Twitbackr が自動的に URL を短縮するので、より長いタイトルを POST できるようになった。
3. Twitter 上での自分のスキンが自動的に適用されるようになった。
4. ameblo で Twitbacker が使えていなかった問題を解決した（たぶん）
5. Twitbackr 関連のみんなのつぶやきがトップページに表示されるようになった。
6. Dashboard (ログイン後のページ) では Twitbackr 関連のあなたのつぶやきが表示されるようになった。

今度のサーバーはすごい気軽にいじれるので、メンテもきっと超高速です！
これからも Twitbackr をよろしくm_ _m

ps.
サポートは Twitter 上の @twitbackr でやっていく予定です。

追記）
現在こちらに移転作業中です。http://twitbackr.com
ping 受付を開始したら、http://twitter.com/twitbackr で通知します。

追記2）
移転作業は無事完了しました。Ping URL の再取得＆再設定をお願いします。
http://twitbackr.com

かれこれ2年程前に作った Twitbacker というサービスが、本日閉鎖されました。

Twitbacker は（なぜか）最近ちらほら使いだしたユーザが増えてたようなので、なおさら残念です。特にユーザ向けの ML とかは無かったので、大半のユーザさんは突然サービスが止まって驚いてるんだろうな。。。ごめんなさい m_ _m

お知らせブログはこのブログの Twitter タグが付いた記事の一覧だったけど、僕もこの件はサービス止まってから知ったし、終了前に記事を書くことはできずでした。

まぁでも、前の会社辞めてからよく一年近くサービスが続いたなぁ〜、というのが正直な感想です。サーバは会社のやつ間借りしてたしね。

まぁコードは手元にあるから、ドメインさえあればその辺の安いレンタルサーバ（というか Heroku）でも十分動くだろうけど、BASIC 認証使ってたり Rails のバージョンが 1.2.3 だったりして、そのままアップは厳しそう。

お盆に時間が取れれば（≒ ネット環境のある場所にいれば）、Twitter と Facebook に投稿できるやつを作ってみるかなぁ〜。

小さい頃に読んだけど、ストーリーは完全に忘れてました。きっと、本で読んだときはあまり面白くなかったんだと思います。

まぁそのおかげで、新鮮な気持ちで見ることができました（笑

カスピアン王子、かっこ良かった！
そして、ルーシーきれい。

次回作の「朝びらき丸 東の海へ」は2010年公開らしいです。朝びらき丸は僕が最初に読んだナルニアシリーズなので、楽しみ♪

ナルニア国物語/第2章:カスピアン王子の角笛 2-Disc・スペシャル・エディション [DVD]

ウォルトディズニースタジオホームエンターテイメント 2008-11-21

売り上げランキング : 3976

おすすめ平均

映画館で5回観ました！

あいかわらず美しいナルニアの自然

これは、傑作。

１章と比べちゃうと

格調の高さ、ユーモアが無くなっています。残念！

by G-Tools , 2009/08/03

もちろんそれ以外にも Content-type が multipart/form-data や application/xml、application/json などの場合も、request body が signature base string に入らないという違いはあるものの、OAuth を使って POST することは可能です。

仕様的には。

smart.fm でも一部 API で multipart (upload file) や xml/json データ (save study data : comming soon) をポストしないといけない API があるのですが、みごと ruby の oauth gem ではそれらに失敗しました。

原因は、OAuth::Consumer#create_http_request の以下の１行。青色の部分を赤色の部分のように変えれば動きます。

module OAuth
  class Consumer
    def create_http_request(http_method, path, *arguments)
      http_method = http_method.to_sym
      
      if [:post, :put].include?(http_method)
        # data = (arguments.shift || {}).reject { |k,v| v.nil? }
        data = arguments.shift
        data.reject! { |k,v| v.nil? } if data.is_a?(Hash)
      end
      
      以下略
  end
end

というところを、github の master ではこの bug が fix されているのですが、rubyforge にはまだ反映されていなくて、ちょっとハマりました。これを fix すれば、こんな感じで POST できます。

access_token.post(path, params, {'Content-Type' => 'multipart/form-data'})
access_token.post(path, xml, {'Content-Type' => 'application/xml'})
access_token.post(path, json, {'Content-Type' => 'application/json'})

また、もし Service Provider が OAuth Request Body Hash という extension をサポートしている場合は、Content-type が x-www-form-urlencoded でなくても post body を signature base string に含めることで、x-www-form-urlencoded 同様セキュアにデータを送ることができます。

実装は既に終わったので、予定通りだと明日の昼前に本番に反映される予定です。

OAuth の脆弱性が発見されてから、暫定的に以下の2つの制約を加えましたが、OAuth 1.0a 対応でどちらの制約も外れます。

1. authorize 時に渡される oauth_callback を無視
2. request token の有効期間もかなり短く

ただし OAuth 1.0a では oauth_callback を指定するタイミングが authorize 時から get request token 時に変更になっているので、authorize 時に oauth_callback 渡しても無効、というのは変わりません。

もちろん従来のフローでアクセスする consumer に対する動作は変わらないので、oauth_callback を利用しない場合は特に consumer 側の変更は必要ありません。consumer 登録時に登録する oauth_callback は、従来通り有効です。

OAuth を利用されている smart.fm API developer の方で oauth_callback を指定したい方は、こちらを参考に該当部分のコードを変更していただければと思います。

get request token 時に oauth_callback を指定

consumer.get_request_token(:oauth_callback => callback)

authorize されて帰って来た時に oauth_verifier を取得

callback の query に oauth_token に加えて oauth_verifier が帰ってくるので、session なりに保存します。（get request token で oauth_callback を指定した時のみ、この oauth_verifier が必要になります）

get access token 時に oauth_verifier を利用

request_token.get_access_token(:oauth_verifier => oauth_verifier)

補足

OAuth 1.0a 未対応のサービスと共存させる為には、authorize_url を生成する場所で以下のようにやってやれば OK です。

authorize_url = if request_token.callback_confirmed?
  # Serveice Provider is supporting OAuth 1.0a
  request_token.authorize_url
else
  request_token.authorize_url + "&oauth_callback=#{callback}"
end

ps.
oauth plugin はそのままだと OAuth 1.0a にしか対応していないので、この plugin を利用している SP の皆様はお気をつけを。