携帯電話のCookie周りについて

携帯電話のCookie周りについて考えてたら、色々まとまらなくなったので、タイトルあいまいで全部ここに書く。
恥ずかしながら携帯Cookie初心者です。
なので、それおかしいよ、とか、或いはとっくに常識だよ、的なこと書くかもしれませんが、ご容赦のほど。

取っ掛かり：DoCoMoのiモードIDについて

これまで、DoCoMoがCookie使えないのを理由として、かつキャリア毎に大きく認証処理変えてたら開発が煩雑だよね、という理由で、3キャリア携帯の端末や個人識別IDをログイン手段として用いて、WILLCOMとか識別IDを出さない仕様の方を、Cookieに擬似ID埋め込んで 無理やり合わせてきた。

でも、考えれば今CookieサポートしてないのはDoCoMoだけなんだし、Cookieベースで作って、DoCoMoの方を合わせるという手もあるよね、と最近思った（というか、まずそう思わないところが携帯脳？）。
で、DoCoMoを合わせる場合、これまではutn属性で一時的なIDしか通知されなかったため、ユーザIDをセッション一意性に利用できない（どころか何らかのセッション機構でユーザID自体を引き回さないといけない）状態だったけど、iモードIDができたことでリクエスト元の一意性が保てるようになったので、システム側のリクエスト受け口/レスポンス吐き口でフィルタしてやって、iモードIDと紐付いた擬似Cookieのような機構を作ってやれば、その下層の開発はCookieでの実装で統一できるよね、と思った。

この方法で、DoCoMo以外の全キャリアがCookieベースで作れるし、DoCoMoは実際には相変わらずiモードIDベースの認証であることには変わりないけど、iモードIDと個人情報の結びつきは疎になるし（iモードIDと紐付くシステム内情報は、最新のセッション情報でしかない）、もしDoCoMoがCookieに対応すればそのまま乗り換えられるし、いいんじゃないだろうか？とか思った。

そんなことを思いついたので、これまでほとんど調査しなかった携帯のCookieについて調べてみた。

au・SoftBankのCookieも一癖も二癖もあり

ところが、単純にDoCoMo以外はCookieを使えばいいよね、というのを考えていたら、au・SoftBankのCookieも一癖も二癖もあることが判った。

その前に、Cookieでセッションを管理する時の基本（というか私も今回知った）だけど、httpとhttpsで別のセッションIDを振ってやらないといけないようだ。
詳細はこの辺だけど、自分でもちょっと解釈するのに時間がかかったので腑分けすると、

• ログイン作業はhttpsでなされるはずなので、認証成功すると、secure属性のついたセッションとついてないセッションの2つを振り出す。httpsなので、このサーバからブラウザへの送信は盗聴されない。
• httpでは、ブラウザはsecure属性のないセッションのみしかサーバに送付しないので、それを使ってセッション管理する。
  これは盗聴されうる。
• httpsでは、ブラウザはsecure属性に関係なく双方のセッションを送付するが、secure属性のないセッションは盗聴されている可能性があるので、secure属性のあるセッションを使ってセッション管理する。

ということだと思う。

ところが、このやり方がau、SoftBankともできなさそう。
ここに記事があるんだけど、

• SoftBankはhttpとhttps間で一切のCookieが共有できない。
  ということはhttpsでログインしてもその情報がhttpでは参照できないということで、どないせーっちゅうねん。
• auは、secure属性のないCookieを作ることができるのだが、その扱いがやっかいで、そのCookieの値がhttpで作られたかhttpsで作られたかによって挙動が変わる。
• • http領域で作られたsecure属性のないCookieは、httpsに移ると参照できない。
  • https領域で作られたsecure属性のないCookieは、httpに移ると参照はできるが、変更・破棄ができない。
  • さらに、https領域で作られたCookieがhttp接続中に有効期限が切れると、http側で再発行されるため、httpsで参照できなくなる
  • なので事実上auでもhttpとhttps間でまともにはCookie共有できないに等しい

といった状況みたいです。

なんとか逃げ道を考えてみたのですが...個人的には以下の方法がよさそうな気が。

• https→http間の情報引き回しは、ワンタイムセッションを発行してやって、クエリストリングベースで引き回す。
  セッションIDのブラウザへの伝達は、https上なので盗聴されず、ブラウザからhttpでサーバにアクセスされると、ワンタイムセッションなのですぐに消去されるので漏洩しない？
• http→https方向の情報引き回しはしない。

何かおかしなところあればツッコミよろしく。

WILLCOM・E-MOBILEはちゃんとCookie実装されてそう

さすが後発組？
仕様書を見る限りでは、3キャリアみたいな無理くりなところがなく、ちゃんと実装されている感じ。
これらでは、普通の技術が使えそう。

• コンテンツ作成マニュアル（WILLCOM）
• 技術情報 | イー・モバイル

iモードIDはhttpsで取れないんだった

最初のセンテンスでiモードIDを使えば擬似Cookieプロキシ的なものを作れるよね、と書いたけど、考えればiモードIDもhttpsでは取れないんだった。
どうすればよかんべ？と思ったが、こんな感じではどうかな。

• http→https間では、iモードID含め情報の引き回しはしない。
  これだとDoCoMoはCookie持たないので、httpsに移る際は100%ログイン作業が必要になるが、まあ仕方ありません。
• httpsでは認証後、クエリストリングベースでセッションを引き回す。
  このセッションの有効期間については検討要。
• https→http間の情報引き回しは、auやSoftBankと同様にクエリストリングベースのワンタイムセッションで、http移行後、ｉモードＩＤベースのセッション管理でよいのではないか。

と言ったあたりを考えてましたが、指摘あればください。

1エントリ・1アイヌリンク：

ユカラネット

関西発の、アイヌ民族の人権問題を考えるサイト。