2012年10月26日金曜日

ドコモかんたん入力

はじめに

「ドコモかんたん入力」というサービスが2012/10/23(火)にはじまりました。これはユーザがドコモに登録している属性情報を、ドコモのサイトからコンテンツプロバイダーのサイトに通知することができるサービスのようです。

報道発表資料 : 「ドコモかんたん入力」の提供開始 | お知らせ | NTTドコモ
http://www.nttdocomo.co.jp/info/news_release/2012/10/18_00.html


属性連携! そう聞いたらどういうプロトコルを使っているのか気になりますよね!?
しかし有料サービスでかつ超お高い!そしてインターフェース仕様は非公開っぽい。

ってことで地道に調べてみました。

準備

早速PCで対応サイト「ファッションウォーカー」のユーザ登録ページから「ドコモかんたん入力」にアクセスしてみると

つれません…
しかもAPNで固定ってことはテザリングでPC繋いでもだめってことですよね…
手持ちのスマホ(Android 2.3)でなんとかがんばるしかありません。
思い浮かぶ手段としては

  1. HTTPのやり取りを見れるブラウザアプリを使う
  2. スマホ内で動作するプロクシアプリとプロクシを指定できるブラウザアプリを組み合わせる
あたりでしょうか。

1は、全てのアプリを試したわけではないですが見つけられませんでした。Firefoxならアドオンが!と思ったけどAndroid版Firefoxでは見つけられませんでした。
2も見つけられませんでした。Firefoxならプロクシは指定できそうでしたがプロクシアプリ側が…

まあHTMLが見れれば大体わかるだろと思ったけどソースを見れるブラウザアプリも意外に見つからない…
いきなりやる気が潰えそうでしたが、とりあえず今回はWebView使ってHTMLを記録するアプリを簡単に作って試してみることにしました。HTTPの電文を見れるアプリかせめてHTMLを見れるアプリ絶賛募集中!

調査結果

改めて「ファッションウォーカー」のサイトの新規メンバー登録にアクセスして、一連の属性連携の画面の流れと次の画面へのフォーム送信内容を見てみました。

図1 新規メンバー登録画面@ファッションウォーカー

表1 「新規メンバー登録画面@ファッションウォーカー」のフォーム
フォームがあるURLhttps://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist
メソッドPOST
フォーム送信先 URLhttps://dei.spmode.ne.jp/udea/sp/gteap001.srv?GUID=ON&uid=NULLGWDOCOMO
以下送信パラメータ
realmhttps://s.fashionwalker.com/
CPID0093059244
p1fashionwalker
p3https://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist
p4https://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist
p500
p7I0101I0102I0103I0104I0105I0106I0107I0109I0112
p220121025223158


図2 ドコモかんたん入力画面@ドコモ

表2 「ドコモかんたん入力画面@ドコモ」のフォーム
フォームがあるURLhttps://dei.spmode.ne.jp/udea/sp/gteap001.srv?GUID=ON&uid=NULLGWDOCOMO
送信メソッドPOST
アクセス先URLgteap001.srv?bis=aud
以下送信パラメータ
GTEAGI002nwAnshoNo(ネッ トワーク暗証番号)
GTEAGI002birthday(生 年月日)
GTEAGI002SubmitDoi以 下に同意して次へ
RequestDeviceIDGTEAGI002
SequenceCheckKey(17 桁の乱数英数字)



図3-1 プロフィール修正画面@ドコモ


図3-2 プロフィール修正画面@ドコモ


図3-3 プロフィール修正画面@ドコモ

表3 「プロフィール修正画面@ドコモ」のフォーム
フォームがあるURLhttps://dei.spmode.ne.jp/udea/sp/gteap001.srv?bis=aud
送信メソッドPOST
アクセス先URLgteap001.srv?bis=aud
以下送信パラメータ
watool_txSequence2_(38 桁の乱数英数字)
RequestDeviceIDGTEAGI003
SequenceCheckKey(17 桁の乱数英数字)
root_GTEAGI003_SHI(氏)
root_GTEAGI003_MEI(名)
root_GTEAGI003_KANASHI(カ ナ氏)
root_GTEAGI003_KANAMEI(カ ナ名)
root_GTEAGI003_NICKNAME(ニッ クネーム)
root_GTEAGI003_SEIBETSU(性 別)
root_GTEAGI003_YEAR(生 年月日_年)
root_GTEAGI003_MONTH(生 年月日_月)
root_GTEAGI003_DAY(生 年月日_日)
root_GTEAGI003_YUBINBANGO(郵 便番号)
root_GTEAGI003_TODOFUKEN(都 道府県)
root_GTEAGI003_SHIKUCHOSON(市 区町村)
root_GTEAGI003_AZACHOME(字・ 丁目)
root_GTEAGI003_BANCHI(番 地)
root_GTEAGI003_MANSHONMEI(マ ンション名)
root_GTEAGI003_TELNOSHIGAI(電 話番号_市外局番)
root_GTEAGI003_TELNOSHINAI(電 話番号_市内局番)
root_GTEAGI003_TELNOKANYUSHA(電 話番号_加入者番号)
root_GTEAGI003_FAXNOSHIGAI(FAX_ 市外局番)
root_GTEAGI003_FAXNOSHINAI(FAX_ 市内局番)
root_GTEAGI003_FAXNOKANYUSHA(FAX_ 加入者番号)
root_GTEAGI003_PCMAILADDRESS(PC メールアドレス)
root_GTEAGI003SubmitKakunin確 認



図4-1 修正内容の確認画面@ドコモ


図4-2 修正内容の確認画面@ドコモ

表4 「修正内容の確認画面@ドコモ」のフォーム
フォームがあるURLhttps://dei.spmode.ne.jp/udea/sp/gteap001.srv?bis=awb&root_GTEAGI003SubmitKakunin=
送信メソッドPOST
アクセス先URLgteap001.srv?bis=awb
以下送信パラメータ
watool_txSequence3_(38 桁の乱数英数字)
RequestDeviceIDGTEAGI004
SequenceCheckKey(17 桁の乱数英数字)
root_GTEAGI004SubmitKakutei確 定


図5 企業への提供確認画面@ドコモ

表5 「企業への提供確認画面@ドコモ」のフォーム
フォームがあるURLhttps://dei.spmode.ne.jp/udea/sp/gteap001.srv?bis=awb&root_GTEAGI004SubmitKakutei=
送信メソッドPOST
アクセス先URLhttps://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist
以下送信パラメータ
CPID0093059244
p1(600 文字以上のBase64文字列)
GTEAGI005SubmitOkOK


(6) 新規メンバー登録画面@ファッションウォーカー


※補足
  • (17 桁の乱数英数字)ってところはこの一連のフロー内ではずっと同一。
  • (38 桁の乱数英数字)も同様。
  • RequestDeviceIDは一瞬ドキッとする名称だけど多分、エンドユーザの端末のIDではないと思う…多分…
  • bis=???の部分は3桁しかないけど微妙に毎回変わる。意図よくわからず。

重要なのは表1のファッションウォーカーからドコモへの送信内容と、表5のドコモからファッションウォーカーへの送信内容ですね。あとは図2の認証に関する画面。
気になる点がいくつか。
  • 表1で「GUID=ON&uid=NULLGWDOCOMO」こんなの送ってますね。SPモードでもまだ使えるんですね。このためにAPNの制限がかかっていたわけか…
  • で、図2の画面で上記で識別したユーザIDに対し、ネットワーク暗証番号と生年月日で認証しているようです。ネットワーク暗証番号の4桁の数字じゃさすがに弱いってことで生年月日も聞いてるんでしょうか?一応4桁のシークレットな数字と組み合わせではありますが、念のため友達は捨てた方がいいのでしょうか?
  • 表5のp1のBase64文字列はBase64デコードしてもバイナリデータになります。事前にドコモとファッションウォーカー間で鍵共有かなんかしていて暗号化しているんでしょう。
  • 表1のp7パラメータはなんか「I」をセパレータに数値のリストを送ってるように見えますね。要求する属性を示す数値だったりするんでしょうか。まあなんかガチガチしてそうなので送信する属性情報も事前に静的に登録させてそうな気もするので違うかもしれませんが。
  • POSTでクエリストリング使うのはできれば避けたいところ
  • …っていうか、完全オレオレプロトコルかよ!

まとめ

docomoIDでOpenIDでAXだー、SREGだー、みたいなのをわずかながらには期待して調べたけど、大方の予想通り、完全なオレオレの塊で全く面白みがありませんでした。時間返せ!

0 件のコメント:

コメントを投稿