Rack::Auth::OpenIDについて探りを入れ始めた

結局は、OpenID認証の仕様を忘れている(というか、そもそも理解できていない)事が分かった。

訳も理解も中途半端に放り投げてしまった結果、トラブルに対応しきれないというのが現状です。

一応、Rack::Auth::OpenIDの使い方についてのイメージは掴めました。結局これは、アプリケーションで、認証保護したいアプリケーションの内部で上手く扱う必要があるのではないでしょうか。ログインアプリ内部でRack::Auth::OpenIDを実行し、OpenID認証の結果を待ち、そのセッションを利用して、保護対象のアプリケーションを保護する、というイメージでとらえています。

ソースをちゃんと読まなかった事が原因でつまずいていた点が、いくつかあります。

  • そもそも、useでは使えない(initializeの第1引数がアプリケーションではない)
  • そもそも、セッション(env['rack.session'])が存在していないと動かない
  • Rack::Auth::OpenIDのアプリケーションへのリクエストURLには、適切なパラメータを渡さないと動かない
  • ここでも、Rack::Lint::LintErrorが立ちはだかる(deploymentで動かせば良い)

今は、YahooをOPとした認証ができないか試しているところですが、どうもRPからOPに投げるリクエストが誤っているようで、Yahooのエラーページが表示されてしまいます。これについては、まずはOpenID認証の仕様書を改めて読まないと解決できないと思っています。以前に用意しておいたYadis IDがあり、それで試しているわけですが、これ自体はfastladder.comをRPとした際にはYahooのログイン画面にまで行けているので、間違っていないだろうと思っています。

ちなみに、この1つ前のエントリで、"~>"について書いたのは、このあたりの調査中に出会った事がきっかけです。ひょっとしたら、OpenID認証の1.1互換モードか、そもそも2.0は使えないのかと疑ってみたりしたわけです。使っている(インストール済み)パッケージは、ruby-openidの2.1.2だけで、かつデバッグ出力に現れたパラメータからネームスペースを確認しても、2.0のsignonを使っているので、互換モードという事も1.1によるものでもない様に思います。

一応、Rack::Auth::OpenIDをrackupで動かすだけのrackup configを貼っておきます。まあ、取り立てて何をしているわけでもありませんが、セッションミドルウェアを事前に有効にしておくのがポイントです。セッションキーは、両者で同じものを使う必要があります(サンプルではデフォルトのままなので、両者ともに'rack.session')。

これ以上については、とりあえず、のんびりと探っていこうと思います。


多分、問題になっているのは、RPのdiscoveryじゃないかという気がしています。ローカルでアプリケーションを動かしているので、OPがreturn_toを使ってRPのdiscoveryを行おうとすると、サーバにつながらずにエラーになるはずです。それが原因で、RPが使えないという意味のエラーページが出ているのでは、とにらんでいます。とりあえずは、ローカルにデモOPをたてて検証をしてみればいいのかな、と。

プロフィール

このブログ記事について

このページは、koshigoeが2008年9月12日 23:55に書いたブログ記事です。

ひとつ前のブログ記事は「"~>"という演算子の意味」です。

次のブログ記事は「Rack::Auth::OpenIDで認証できた」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。