えー、おなじみ高木浩光先生が
クッキー食えないのはドコモだけなんて記事で「携帯でもユーザ認証のセッション管理にCookieを使うべき」と書かれてますが、元高木番記者・現プログラマとして一言。
実は携帯のユーザ認証の真の問題は「Cookieが食えない」ことではなく、「
SSL環境と非SSL環境でCookieが変わってしまう」ことなのですよ。
高木先生が参照している元記事(
携帯Webのクッキー利用について調べてみたメモ【update】)でも書かれてますが、まずauは
・SSL接続時:端末にCookieを保存
・非SSL接続時:EZサーバ(ゲートウェイ)にCookieを保存
という構成になっているため、SSL接続状態で認証を済ませても非SSLに戻った瞬間にCookieが変わってしまう(=セッションが引き継がれない)ため、非認証状態に戻ってしまいます。
またSoftBankは、通常SSL接続時にはURLを勝手に「https://secure.softbank.ne.jp/~」という形に書き換えて、半強制的にソフトバンクのSSLゲートウェイを通る接続にしてしまいますが、このためSSL時に発行したCookieは「secure.softbank.ne.jp」の中でしか有効になりません(おそらく端末まで届いてないと思われる)。このため非SSLに戻った瞬間に同様にCookieが変わってしまいます。
#ドコモのCookie対応端末の挙動がどうなるかは、i-mode 2.0対応端末が手元にないのでまだ調べてません。誰か検証可能な方よろしく。
#e-mobileは細かいところは未検証ですが、確か以前試した記憶では、SSL・非SSLを問わず同じCookieが使えたような…(うろ覚え)。
これを防ぐには、結局
○ユーザ認証後の全ての処理をSSL上で行う
○セッションIDをURLの引数として引き回す
の2択を迫られることになり、現実的に現在の携帯電話では全てをSSL上で行うのはまだまだ非現実的なのと(性能的にはAll SSLでも行けると思うんですが、いちいち「SSLで接続します」等のダイアログが出てしまうため、あまりサイト提供者側の受けがよろしくない)、ドコモの旧機種がCookieが使えないことの関係から、後者を選択せざるを得なくなるのが現状なわけです。
とりあえずau・SoftBankの両社には、今からでも遅くないので
○Cookieは全て端末側で管理
○SSL接続時に余計なURLの書き換えを行わない
の2つを行って欲しいところ。