はじめに
「ドコモかんたん入力」というサービスが2012/10/23(火)にはじまりました。これはユーザがドコモに登録している属性情報を、ドコモのサイトからコンテンツプロバイダーのサイトに通知することができるサービスのようです。報道発表資料 : 「ドコモかんたん入力」の提供開始 | お知らせ | NTTドコモ
http://www.nttdocomo.co.jp/info/news_release/2012/10/18_00.html
属性連携! そう聞いたらどういうプロトコルを使っているのか気になりますよね!?
しかし有料サービスでかつ超お高い!そしてインターフェース仕様は非公開っぽい。
ってことで地道に調べてみました。
準備
早速PCで対応サイト「ファッションウォーカー」のユーザ登録ページから「ドコモかんたん入力」にアクセスしてみるとつれません…
しかもAPNで固定ってことはテザリングでPC繋いでもだめってことですよね…
手持ちのスマホ(Android 2.3)でなんとかがんばるしかありません。
思い浮かぶ手段としては
- HTTPのやり取りを見れるブラウザアプリを使う
- スマホ内で動作するプロクシアプリとプロクシを指定できるブラウザアプリを組み合わせる
あたりでしょうか。
1は、全てのアプリを試したわけではないですが見つけられませんでした。Firefoxならアドオンが!と思ったけどAndroid版Firefoxでは見つけられませんでした。
2も見つけられませんでした。Firefoxならプロクシは指定できそうでしたがプロクシアプリ側が…
まあHTMLが見れれば大体わかるだろと思ったけどソースを見れるブラウザアプリも意外に見つからない…
いきなりやる気が潰えそうでしたが、とりあえず今回はWebView使ってHTMLを記録するアプリを簡単に作って試してみることにしました。HTTPの電文を見れるアプリかせめてHTMLを見れるアプリ絶賛募集中!
調査結果
改めて「ファッションウォーカー」のサイトの新規メンバー登録にアクセスして、一連の属性連携の画面の流れと次の画面へのフォーム送信内容を見てみました。
図1 新規メンバー登録画面@ファッションウォーカー
表1 「新規メンバー登録画面@ファッションウォーカー」のフォーム
フォームがあるURL | https://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist |
メソッド | POST |
フォーム送信先 URL | https://dei.spmode.ne.jp/udea/sp/gteap001.srv?GUID=ON&uid=NULLGWDOCOMO |
以下送信パラメータ | |
realm | https://s.fashionwalker.com/ |
CPID | 0093059244 |
p1 | fashionwalker |
p3 | https://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist |
p4 | https://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist |
p5 | 00 |
p7 | I0101I0102I0103I0104I0105I0106I0107I0109I0112 |
p2 | 20121025223158 |
図2 ドコモかんたん入力画面@ドコモ
表2 「ドコモかんたん入力画面@ドコモ」のフォーム
フォームがあるURL | https://dei.spmode.ne.jp/udea/sp/gteap001.srv?GUID=ON&uid=NULLGWDOCOMO |
送信メソッド | POST |
アクセス先URL | gteap001.srv?bis=aud |
以下送信パラメータ | |
GTEAGI002nwAnshoNo | (ネッ トワーク暗証番号) |
GTEAGI002birthday | (生 年月日) |
GTEAGI002SubmitDoi | 以 下に同意して次へ |
RequestDeviceID | GTEAGI002 |
SequenceCheckKey | (17 桁の乱数英数字) |
図3-1 プロフィール修正画面@ドコモ
図3-2 プロフィール修正画面@ドコモ
図3-3 プロフィール修正画面@ドコモ
表3 「プロフィール修正画面@ドコモ」のフォーム
フォームがあるURL | https://dei.spmode.ne.jp/udea/sp/gteap001.srv?bis=aud |
送信メソッド | POST |
アクセス先URL | gteap001.srv?bis=aud |
以下送信パラメータ | |
watool_txSequence | 2_(38 桁の乱数英数字) |
RequestDeviceID | GTEAGI003 |
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 「修正内容の確認画面@ドコモ」のフォーム
フォームがあるURL | https://dei.spmode.ne.jp/udea/sp/gteap001.srv?bis=awb&root_GTEAGI003SubmitKakunin= |
送信メソッド | POST |
アクセス先URL | gteap001.srv?bis=awb |
以下送信パラメータ | |
watool_txSequence | 3_(38 桁の乱数英数字) |
RequestDeviceID | GTEAGI004 |
SequenceCheckKey | (17 桁の乱数英数字) |
root_GTEAGI004SubmitKakutei | 確 定 |
図5 企業への提供確認画面@ドコモ
表5 「企業への提供確認画面@ドコモ」のフォーム
フォームがあるURL | https://dei.spmode.ne.jp/udea/sp/gteap001.srv?bis=awb&root_GTEAGI004SubmitKakutei= |
送信メソッド | POST |
アクセス先URL | https://s.fashionwalker.com/fw/b/pc/NewMember.html?mthd=goCustomerRegist |
以下送信パラメータ | |
CPID | 0093059244 |
p1 | (600 文字以上のBase64文字列) |
GTEAGI005SubmitOk | OK |
(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 件のコメント:
コメントを投稿