API出品？複数アカウント切替？メルカリの通信内容を解析してみる②

<前回の記事>
API出品？複数アカウント切替？メルカリの通信内容を解析してみる①

 

前回、目標は「アカウントの切り替え」と書きましたが、検証中の段階で切り替えは怖いのでとりあえず1アカでのログイン、ログアウトのみを試してみます。（そもそも”できたら”の話ですが（笑））

ログイン時のリクエスト内容を確認する

それでは早速、ログイン時に送信されているリクエストの内容を見てみましょう。

こちらが要求ヘッダーの中身。

応答ヘッダーの方は文字通り要求に対するサーバ側からの回答だと思いますので、まだ確認しなくても大丈夫でしょう。

 

私もこの辺の処理は初見ですので、一つずつどういうものか確認していきます。

Host	リクエスト先サーバ名。DNS名を利用する。1.1ではプロキシや仮想サーバの利用を前提に、必須としている
User-Agent	Webブラウザの固有情報
Accept	利用可能なアプリケーション・メディアタイプ。複数指定、優先度指定も可能
Accept-Language	利用可能な言語コード。複数指定し、優先度を付けることが可能
Accept-Encoding	利用可能なエンコーディング形式（Content Coding形式）
Referer	直前にリンクされていたURL
Content-Type	リソース・コンテンツのアプリケーション・メディアタイプ。MIMEのメディアタイプと同様
Content-Length	リソース・コンテンツのサイズ。単位はバイト
Connection	接続の永続性情報。’none’が指定されると、レスポンス後の接続は解除される
Upgrade-Insecure-Requests	サーバ側が「https」に対応しているかどうかを確認するためのものらしい。

【参考サイト】
■http://www.atmarkit.co.jp/fnetwork/rensai/netpro01/header-fields.html
■https://www.suzukikenichi.com/blog/content-security-policy-upgrade-insecure-requests-can-resolve-mixed-content/

 

なるほど、この辺は何か固定値でいけそうな気はしますね。

問題は・・・Cookieか・・・。

 

ブラウザ操作だとIEが勝手に処理してくれるので問題無いのですが、リクエストをこちらで作るとなるとCookie周りの処理も自分で行う必要がありますね。

正直手を出したく無い。

 

というかプログラムでリクエスト組んで送信する時ってどこまでの項目指定すれば良いんだ・・・？HTMLドキュメント取ってくるだけならURLだけあれば良いんだけど、認証に使う場合がいまいち分からない。

 

 

 

 

・・・まぁそこは一旦後回してにして、次は送信パラメータの部分でも見てみますか。

えーっと「email」、「password」は入力したものがそのままセットされていますね。

次は「g-recap・・・」

 

あっ

 

 

 

 

 

 

 

 

 

えー・・・どういうことかと言うと。

多分これ↑のチェックを入れた際に返って来る”とあるコード”がこの「g-recaptcha-response」にセットされて送られている感じです。

 

つまり、このreCAPTCHAをどうにかして回避しないとログインできないという事で良いと思います。

これはちょっと・・・ログイン処理は絶望的かなぁ。 

出品時のリクエスト内容を確認する

通信内容を見る限りログアウト処理だけなら実装できそうですが、ログインはちょっと難易度高そうです・・・

という事でもう本題が終了してしまいましたが、ログインは一旦諦めましょう。

 

もう一つ実装して見たかったもの、APIを使った出品処理はできそうかどうかも確認してみます。

パラメータとして送信していたデータはこんな感じでした。

基本的な設定内容については大体そのまんまですね。

面倒な事と言えば画像ファイルをbase64のテキストデータにエンコードしなければいけないという所でしょうか。

 

しかし問題は最後の2項目・・・

「_csrf_value」と「exhibit_token」はどこから出てきたのか。

CSRFについて

あまり聞き慣れない単語だったので調べてみたら以下の攻撃手法がヒットしました。

クロサイトリクエストフォージェリ（※wikipediaが別タブで開きます）

名前だけは聞いた事ありますが、ネットワーク系の内容には疎いものでほんと名前しか覚えて無かったですね・・・

 

 

 

 

まぁ実はこれについてはラクマの出品機能を実装していた時の事を思い出したのですぐに分かりました。

どういう事かと言うと、ラクマって出品ページに遷移した時点で既に出品用のIDが発行されているんですよね。

上記の様に、出品ページに遷移した時のURL末尾部分がIDとなっています。

 

なので、メルカリでも同じじゃないかと思い出品ページ遷移後のHTMLソース内を確認してみた所・・・

 

 

ありました。

 

フッターより更に下のあたりによく分からない英数字の羅列が存在したので、とりあえずexhibit_tokenの文字数（32文字）と比較した所、文字数が一致。

という事でこの部分に当たりを付けた後、値をコピーしておいて試しに出品して見た所、「_csrf_value」と「exhibit_token」の値がそれぞれ上記部分の文字列と一致しました。

 

これでパラメータに必要なデータは全て揃ったことになりますね。

データを飛ばす際はJSON形式にする必要があるみたいなので、後は組み立てて送信できればOKといった感じでしょうか。
※JSON形式について（IBM様のサイトが別タブで開きます）

うん、出品だけなら何とか頑張ればいけなくも無いかもしれない！

 

今後の取り組みについて

さて、ログイン処理は難しそうですが、出品自体は頑張れば行けそういう雰囲気でした。

 

仮に出品処理をAPIで実装した場合にツールとしてどんなメリットがあるかと言うと、「安定して確実に出品ができる」というのが一番のメリットだと思います。

現在私が配布しているExcelベースのツールを使った事がある方なら分かると思いますが、”出品したい内容の通りに設定がされない事”が稀にあります。

特にカテゴリなどの選択肢部分ですね。

 

あの辺はキーボードの下キーを連打している様な処理なので、裏でゲーム等の重たい処理を行っている場合はキー情報の受け渡しとIE側の処理が間に合わず、目的のカテゴリの選択が完了する前に次の項目の選択に処理が移ってしまいます。（処理間隔をsleep秒数で管理しているため）

選択肢がうまく設定できなくなる理由はそれだけでは無いのですが・・・APIを使うとその辺の問題が一気に解消する訳です。

 

で、ツールにAPIを使った出品機能を実装するかというと・・・

 

 

 

 

 

実装しません。

たかが無料配布ツール。そこまで正確さを求めても私個人にメリットがありません。

ログイン/ログアウト処理も実装してアカウントの切り替えまでできる様になるのであれば意味はありますが、切り替えが実装できない以上出品部分のみ作り上げてもしょうが無いからです。

 

「頑張って作り上げた分、有料ツールにして販売しちゃえば？」

と思ってくれる方も居るとは思いますが、残念ながらそれはできません。

お金をもらってツールを渡す仕組みにしちゃうと、メルカリ専属の弁護士がすっ飛んで来ちゃうらしいですからね・・・

 

そもそも公開されてないAPIを割り出して使おうなんてだめだよね！（今更）

 

 

 

さて、新しい事にチャレンジしてみようと思い色々調べてきましたが、残念ながら今回は実装せずという事で終わりです。

私も自分の副業だったりゲームしたり（？）アニメ見たり（？）で色々忙しいんでね！

また何か思い付いた事があれば手を出してみようと思います。

 

 

最後に一つ。

今回ログインの実装は難しいとか書きましたが、多分色々間違ってる所があると思うので本当はreCAPTCHAとか考える必要無かったりするのかもしれません。

他の言語だと簡単に実装できる可能性もあるので、「挑戦してみたい！」と思う方はぜひ頑張ってみて下さい。