vol3:今や昔ドコモあるある(懐かしの Guid=ON)

GUIDON

こんばんは

なかなか忙しくて、ブログを書く時間が取れません、、

本実も軽めの記事にします。

最近ではほとんど無視していいことに無っっちゃった、携帯サイト。

若いエンジニアの方は、もう知らないでしょうね。

携帯IDやら、簡単ログインやら、携帯でしか使えないタグとか、、、

と、ここで携帯ID出てきましたね。

なんのこっちゃと思う方もいると思いますが、

昔の携帯って独自ブラウザを搭載していたんですね。

これが厄介。

独自ブラウザは、インターネットに直接出ることはなく

各キャリアのゲートウェイサーバーというのを介してインターネットに出るわけです。

この独自の仕組みを作り上げた日本の各キャリアは

世界で最速で携帯での課金システムを作り上げることに、成功し

その成功に酔いしれ、固執するあまり

今のスマフォでのネットワークに後輩を期することになりました。

という細かい説明はさておき、

先ほど出てきた各キャリアのゲートウェイサーバ。

これが携帯から通信されるID、細かく言うとSIMの情報をゲートウェイサーバーが受け取り、個人を特定し、それぞれのキャリアが管理している、独自のIDをHTTP Header に乗せてくれていたのです。

これが携帯IDと呼ばれるものです。

HTTP Header を特定すれば、個人を特定できる。

個人を特定できると言っても、個人情報が漏れるわけではなく、IDを取得できるだけです。

各キャリアに公式に認められたサイトはこのIDで各キャリアに課金の請求ができたんですね。

だから大流行り、どこもかしこも携帯サイト祭りでした。

現状を考えると、何だったんだろうという、一時的な流行です。

携帯サイト(正確には携帯の独自ブラウザが)はその昔は、cookieが使えなく(特にDOCOMOはしつこかった)

この携帯IDで個人を特定することによって、ログインのステータスを管理していたんですね。

あー懐かし。よくこんなのやってたな。

なので一度ログインすると、もう次から携帯IDで認識すればよいので、ログインの行為が入らなかったりしたんですよ。(cookieみたいに有効期限がないので、、)

毎回 HTTP Headerに個人を特定できる携帯IDが送信されているので、リクエストがきたら、もう前に来た、あのユーザーだーってわかっちゃうわけです。

これがいわゆる「簡単ログイン」と呼ばれたものでした。

日本が世界に誇って、錆びれていった、独自携帯システムです。

おそらくこんなシステム日本だけだったと思います。

この中で、さらに独自路線まっしぐらだったのが、その名もDOCOMO

この携帯IDをつける時と、つけない時を使い分けることができたんですね。

それが Guid=ON

これが URLパラメータにある時は携帯IDをHTTP Headerに付与するが

ない時は、付与しないんです。

わかっちゃいるけど、ついつい、、

ということでやっちゃいました。

実際本番アップした後に、問い合わせが、、

お客様
DOCOMO携帯でログインできないんですけど、、

懐かしいと思ってくれた人もいるはず、

そんなあなたは確実に35歳以上です。はい。

聞いた瞬間

あ!!!

もう不具合であることは間違いありません。

なんとなく別の会社から引き継いで、機能追加をしたんですが、

どうやってGuid=On をパラメーターにつけているんだろう?

とふと疑問が湧いていたのですが、

PCでの携帯シミュレーターでうまく動作していたので、ドーンと本番アップしちゃいました。

不具合が起きた後になれば、なんでちゃんと携帯の実機でテストしなかったの?

とか、DOCOMO専用のシミュレーターでなんでテストしなかったの?

結果論から言えば、なんとでも言えます。

あとだしジャンケンなら、なんとでも言えます。

はぁ、

Guid=On が付いていなかった箇所があったんですね。

そのため携帯 IDがなく、個人を特定することができないので、ログインができない状態になっていました。

はい本日の教訓

ひとーつ:できる限り、本番に近い環境でテストすること!!

これを機に会社に各キャリア(Docomo、au、softbank)の携帯を買ってもらい、同じテストを毎回3キャリア分テストすることになりました。

この時の不具合の解消方法ですが、このGuid=Onを必ずパラメータに乗せるための共通関数がもともと用意されていたんですね。

でも他の会社から引き継いだばかりで、よくわかっておらず、URLを普通に書いてしまっていたため、Guid=On がつかない状態となってしまったのです。

まぁ今でも Javaのstruts とかで、sessionid をURLの後ろにつけるとか、つけないとかのオプションありますよね。

未だに、何らかの理由で、cookieを使わずに、パラメーターに乗せて、ログインセッションをコントロールしているシステムは数多くあります。

それぞれの開発の中でのルールがあると思いますので、気を引き締めていきましょう。

短く終わるつもりだったんですが、携帯サイトの話で、結局長くなっちゃいました。

ではでは、おやすみなさい。

にほんブログ村 IT技術ブログへ
にほんブログ村


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です