認証関連を改修中
バージョン0.9.9（とCookieManagerの改造）でcookieの受け渡しがそれなりに出来るようになりまして。そうなると、これまで放置していた認証に関するあれこれをちゃんとしとかんといかんわな、ということで試行錯誤してみてます。
現在、デモサイトのものに以下の改修を試しに施してみています。「これこうしたほうがいいよ」とか、なにかお気づきになった点があればお知らせください。
改修ポイントそのいち。
アクセス先のページ内のフォームをのメソッドを全てPOSTに変更してみました。これまではとにかくなんでもかんでもGETだったので、パスワードすらURLにそのまま表示されていたわけですが、それはヤバいだろうと。しかしパスワードを入力させるフォームが必ずPOSTであるとも限らないので、とにかく全部POSTにしてみました（もちろん、アクセス先には元々のメソッドで送信されます）。もっとも、Pragma: no-cacheが効いちゃう端末だとセッション有効時にはウザイかも。なので、元々のメソッドがPOSTの場合のみPOSTでそれ以外はGET、というように変更するかも。
なお、POSTに対応してない携帯もあるわけで、そのため、これまではなんでもかんでもGETにしていたわけですが。把握してる限りでは、User-Agentが「J-PHONE/2.0」で始まる端末がそれなので、これらは従来通り、なんでもかんでもGETのままです（確かAir H"もそうだったと思うけど、これは端から対応を考えていないので無視）。ちなみに、これに伴いDetectClientの仕様も微妙に変更。
改修そのに。
基本認証（Basic Authentication）に対応してみました。いまどき基本認証を採用しているサイトは多くないとは思いますが、フォームからの認証はOKなのに基本認証はNGというのは中途半端だよなと。なお、ダイジェスト認証は、HTTP_Requestが対応してないのでパス。
これはやはりセッションを利用しています。レスポンスコードが401の場合、ホスト名とrealmとパスに合致するユーザ名とパスワードがセッションデータに保存されている場合はそれを送信し、なければ入力フォームを表示します（パスは前方一致）。なお、入力値はホスト名＋realm（のハッシュ値）をキーに保存されるので、新しい入力があった場合、既存のものとホストとrealmが同一の場合、値は上書きされます。
ところで、一般的なウェブブラウザはいったん認証がなされると、以降は自動的にAuthorizationヘッダを付加し、ユーザの入力は省略されるという実装になってると思いますが、ここで、自動的にヘッダを付加している範囲はどういう定義になってるんだろう？あれこれ実験してみた限りでは、同一ホスト名なら、パスやrealmなどに関わらず送信しているようなのだけど…。上述の通り、ここではホスト名とrealmとパスが合致した場合のみの送信としているので、こうしたウェブブラウザとはちょいと動作が違ってます。
以上はデモサイトでは実施済みです。あとは、cookieが使える端末はそっちを使おうか、とか、端末ID（サブスクライバID）を使おうか、とか。
2006/03/17
トラックバック
このエントリーのトラックバックURL:
http://www.rcdtokyo.com/mt/mt-rcdtokyo5428-tb.cgi/724
コメント
おほっ
これでパスワード丸出しから解放されるのですね。BASIC認証は数は少ないのでしょうが回っていると意外とぶつかるので助かります。
COOKIEはそのまま使えると助かりますが、サブスクライバなんかも検討ってことはもすかすてキャリア替えですか？
Posted by 名無しさん at 2006/03/18 02:03
いまのウンコmovaがあちこちぶっ壊れ始めてるので、さすがにそろそろ機種変更するかもしれませんが、諸般の事情によりキャリアは変わらんです。
で、いまのウンコmovaは端末IDの類に対応してないので、このあたりを実装しようとすると、実機検証には機種変更必須なわけですが、さてどうすっかなあ。
Posted by ucbさん at 2006/03/19 13:39
_ ∩
( ﾟ∀ﾟ)彡 FOMA！FOMA！
⊂彡
ん？でもドコモってクッキー食べませんよね。
Posted by 名無しさん at 2006/03/20 17:07
昨日うちのニョーボのケータイがFOMAになりました。しかし、俺様のケータイは相変わらず端末IDすら取れないウンコmovaのままです（実話）。
さて、ちょいとまたデモサイトの実装を変えました。
まずは、セッションが常時ONになってます（従来の「SID」チェックボックスは「REF」に変わっていて、これはReferer送信の有無だけが切り替わります）。
で、cookieが有効な端末は、セッションIDがcookieに埋め込まれようになってる筈。
また、今までセッションの無効化（データの削除）はデフォルトのガベージコレクションルーティンに任せてたわけですが、最終アクセス時刻を記録するように変更していて、一定時間（デモサイトでは10分）が経過しているセッションデータは空配列に初期化されます。
さらに、セッションの乗っ取り防止で、セッションデータの生成時に、IPアドレスとUser-Agentと端末ID（いずれも、取得できないものについてはNULL）を連結した文字列（のハッシュ値）を埋めておいて、そのセッションIDでアクセスしてきた端末が、これに合致しない場合、セッションデータはやはり空配列に初期化されます。
ただし、ここで利用している端末IDは、ダマテンで取得できるもののみで、つまりドコモの場合は一切取得しません（ドコモの場合IDを送信しようとする都度確認画面が表示される）。てなことで、ドコモと一部J-PHONEについてはまだアマアマセキュリティですが、前よりはマシかと。
試して試して♪
Posted by ucbさん at 2006/03/21 00:13
…と思ったら、携帯の串って、通信の都度にガンガン変わりやがるのね（iモードだけ？）。初期化されまくりじゃんorz
Posted by ucbさん at 2006/03/21 02:16
なんだかauにとってもやさしい仕様に。セッションもしっかり機能してるみたいですね。
端末ID関連が正常に動いてるかは見るすべがないので分かりませんが、多分大丈夫ぽ？
串ならauも多分同じですお。
Posted by 名無しさん at 2006/03/21 21:17
いつまでもコメント欄に書いてるのもアレなんだけど、仕様が固まってるわけでもないので。
ここまでのまとめ。
セッションを乗っ取られる懸念が薄いと思われるクライアントについては別途にセッションの有効期限を設けらるようにしました。これは、cookieが有効か、または端末IDが取得可能でかつ正当なリモホ（と思われる）の場合で、この場合セッションは、現在のデモサイトでは、最終アクセスから6時間存続します。そうでない場合は、従来通り10分。
アクセス履歴の参照機能を追加しました。下部メニューの「履」リンクで、（同一セッション中に）それまでアクセスしたページのリストが表示されます。
「次」などのURLの仕様を変更。これまでは全てのパラメをgetしてましたが、せっかくフォームからの送信をpostに変更したのに、こっちのURLでは丸見えだったのでこれをやめ、アクセス履歴を参照するように変更しました。なので、アクセス履歴が保存されない＝セッションが無効の場合は従来通り丸見えのままさ。
ついでに。認証系じゃないんだけど、これまえではP&BRに変換していたUL|OL|LIをそのまま残すようにしてみました。ページ分割時の処理（入れ子の場合があるのでメンドー）が加わっているので、また処理が重くなったかもなorz
これ、不評だったらやめます。
Posted by ucbさん at 2006/03/22 23:39