「mixi station」プロトコルメモ
STATUS: 故障中x2
「mixi ミュージック」に再生曲リストを登録するためのクライアントソフト「mixi station」がmixiのサーバと通信している内容を調べてみました。
代替クライアントとか作れないかもくろんでいます。
※ はてなだとインデントとか改行がむちゃくちゃなので、/.のほう見たほうがいいかも。→こっち
● mixi ミュージック用サーバ
次の２つのサーバがあるようです。
・upload.mixi.jp (202.221.63.14)
再生曲リストをアップロードするためのサーバ
ユーザーのメールアドレス/パスワードからセッションIDを取得するのにも使用されるているようです。
・download.mixi.jp (202.221.63.12, 202.221.63.21)
mixi stationの自動アップデートのためのサーバ
起動時に最新版があるかチェックいっているようです。
● 再生曲リストアップロード
アップロード用のサーバ(upload.mixi.jp)へ、HTTP(port80)でリクエストをPOSTします。
データ内容は、セッションID(session_id)と、再生曲リスト(data)からなります。
下のリクエスト例での <セッションID>には実際にはセッションIDが入ります。
セッションIDは、mixi stationの設定画面でユーザー名/パスワードを登録した際にアップロードサーバから取得されます。
このセッションIDは、mixiにログインする際に使用されるセッションID（これは、ブラウザのCookieとして保存されている)とは別の値が割り振られています。
ブラウザでmixiをログアウトしても、mixi station用に取得したセッションIDは有効なままでした。
再生曲リストのデータ部分は、XMLになっています。
文字コードは、UTF-8。
形式はみたまんまです。
複数の再生曲を一度のアップロードする場合は、を複数記述可です。
telnetで直接リクエストを送ってみたらうまくいったので、特に難しいこと考えなくても再生曲リストをアップロードすることは出来るでしょう。セッションIDさえわかってれば…
【概要】
サーバ：upload.mixi.jp
ポート：80 (HTTP)
通信タイミング：曲再生完了後
通信内容：セッションID,再生曲リスト (結果を取得)
POST /music/upload.pl HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 367
User-Agent: mmm/v0.1 (by glucose)
Host: upload.mixi.jp
Cache-Control: no-cache
session_id=<セッションID>&data=
【レスポンス例】（成功）
HTTP/1.1 200 OK
Date: Tue, 23 May 2006 16:44:14 GMT
Server: Apache
Content-Type: text/plain; charset=EUC-JP
Connection: close
Transfer-Encoding: chunked
a
status=OK
0
【レスポンス例】（失敗:セッションIDが不正）
HTTP/1.1 200 OK
Date: Tue, 23 May 2006 16:44:59 GMT
Server: Apache
Content-Type: text/plain; charset=EUC-JP
Connection: close
Transfer-Encoding: chunked
13
status=BAD_SESSION
0
【レスポンス例】（失敗:データ形式エラー）
HTTP/1.1 200 OK
Date: Tue, 23 May 2006 16:04:37 GMT
Server: Apache
Content-Type: text/plain; charset=EUC-JP
Connection: close
Transfer-Encoding: chunked
10
status=BAD_DATA
0
● セッションIDの取得 (よくわからない)
再生曲リストをアップロードする際には、セッションIDで認証されます。
セッションIDは、前述したとおり、mixi stationの設定画面でメールアドレス/パスワードを設定した際に、アップロード用のサーバ(upload.mixi.jp)へ、HTTPS(port443)でリクエストされます。
が、SSLで暗号化されているので何を通信しているのかわかりません。
これには困りました。
mixi station自体、セッションIDを起動ごとに毎回取得しているわけではないようなので、どこかのファイルに記録しているはずなのですが、これもよくわかりませんでした。
後述する設定ファイルにもそれらしい項目はありませんでした。
困ったね。
（FileMonとRegMonで調査中)
【概要】
サーバ：upload.mixi.jp
ポート：443 (HTTPS)
通信タイミング：設定画面でメールアドレス/パスワードを設定した際
通信内容：メールアドレス/パスワード (セッションIDを取得) ※推定
● mixi stationクライアントソフトアップデート
起動時にダウンロード用のサーバ(download.mixi.jp)へ、HTTP(port80)でリクエストをgetしているようです。
クライアントソフトの最新版があるかのチェックおよび自動アップデートを行うとおもわれます。
クライアントのバージョン等はリクエストのbody部分にないので、UserAgentあたりをみて判断しているのかもしれません。
また、「更新あり」のレスポンスが返ってきても特になにも処理されないため、自動アップデートはまだ実装されていないのかもしれません。
起動するごとに「更新あり」「更新なし」のレスポンスが交互にかえってきました。
ユーザー認証は、Cookieに記録されているmixiのセッションID（BF_SESSIONとBF_STAMP)をもとにしているように見えます。
ブラウザでmixiをログアウトすると、常に「更新なし」のレスポンスが返ってきました。
【概要】
サーバ：download.mixi.jp
ポート：80 (HTTP)
通信タイミング：mixi station 起動時
通信内容：バージョン情報(UserAgentかな) (クライアント更新情報を取得)
【リクエスト例】
GET /station/update/mixi_win.plist HTTP/1.1
If-Modified-Since: Mon, 08 May 2006 09:32:50 GMT
If-None-Match: "219000d-3e4-8dd31480"
User-Agent: glucose updater v2.0
Host: download.mixi.jp
Connection: Keep-Alive
Cookie: BF_SESSION=
【レスポンス例】(更新がある場合) ※文字コードはUTF-8
HTTP/1.1 200 OK
Date: Tue, 23 May 2006 15:41:19 GMT
Server: Apache/2.0.54 (Unix)
Last-Modified: Mon, 08 May 2006 09:32:50 GMT
ETag: "b98007-3e4-8dd31480"
Accept-Ranges: bytes
Content-Length: 996
Connection: close
Content-Type: text/plain
正常に動作をおこなうために、最新版へのバージョンアップをおこないますか？(推薦)
【レスポンス例】(更新がない場合)
HTTP/1.1 304 Not Modified
Date: Tue, 23 May 2006 16:03:28 GMT
Server: Apache/2.0.54 (Unix)
Connection: close
ETag: "219000d-3e4-8dd31480"
● mixi station の設定ファイル
・レジストリ
「HKEY_LOCAL_MACHINE\SOFTWARE\mixi\mixi station\」
exeファイルのパスが記録された「Application Path」くらいしか見るべきキーがありません。
他にインストーラが使用しているレジストリがありましたが、動作には関係なさそう。
・ファイル
「C:\Documents and Settings\<ユーザー名>\Application Data\mixi\mixi\mixi.plist」
ユーザー名/パスワード(暗号化されて記録)、および再生リストが記録されているXMLファイルです。
パスワードは、妙に長いのでここにセッションIDも一緒に記録されているのかも。
