噂通り、3/14にNike Air Force 1 Lowのリストックがありました。
代行料金は以下となりました。
- Nike Air Force 1 Low White 3,000円
- Nike Air Force 1 Low Black 2,500円
前回からの改良
前日のNikeコラボでは、リクエスト型で相変わらずの「high traffic」エラーが出てしまいました。
色々調べてみましたが、どうやら決済ページをbypassしていることが原因のようです。どのような形でbypassを検知しているのか完全には把握できておりませんが、今回はリクエスト型とモバイルブラウザ型を併用する方法を試してみました。
どのような方法かと言うと、カートインしたあとブラウザでモバイルの決済画面に遷移させ、チェックアウトのみ直接リクエストで送信する方法です。完全なリクエスト型ではないため、あまり意味はありませんが、この時にCookieの内容をログとして書き出すことにしました。
SupremeのJavaScriptを調べてみると、決済リクエストの前に以下のような処理が走っていました。
submitFormAfterCaptcha: function(e) {
window.pookyCallback && window.pookyCallback(), $(“#cookie-sub”).val(this.cookieSubValue());
どうやら2年位前のBot対策を調べてみると、pookyという方法でBot対策していたことがあるようです。現在もこの方法が使われているのか不明ですが、リリース日にBot対策の機能が有効となり、特別なCookieが書き込まれるようです。現在はこれがTicketという方法に置き換わっている可能性もありますが不明です。
今回の結果
今回は7件ほどの依頼となりました。用意できるクレカの在庫が少なかったため、少数の募集となりました。
Botの改良や前日のログを調査していたら結局また朝になってしまいました。
そして、いよいよ11時になった瞬間、在庫がなくなりました。手動で買えた方はほぼ居なかったのではないでしょうか…。
ログを調べてみると、10時59分52秒あたりで商品情報が更新され、リストックされたようです。11時ちょうどに決済を通した段階ですでに在庫不足で購入できませんでした。
これはだめか…と思いましたが、なんとか1件のみ注文に成功し、注文完了メールを受信しました。もう1件はオーダー済みエラーとなりましたが、こちらはメールが届かず、別の代行業者さんに依頼されたのが成功したのかもしれません。
調べてみると今回改良したリクエスト型で注文が通っていました。考えられるのは以下のパターンです。
- 一度決済ページに遷移させることでBot検知を回避できた。
- リストックであったため、Bot対策が有効となっていなかった。
念のため「window.pookyCallback」がセットされるのか監視していましたが、今回は確認ができませんでした。Cookieも特別な値は確認できません。Bot対策が有効となっていなかったのか、それとも昔使われたコードがそのまま残っているだけなのかまだ不明です。次回のリリース日もチェックする必要はありそうです。
決済ページに遷移する必要があると、どうしても決済処理まで時間がかかりすぎるため、これだとあまり意味がありません。これをbypassする方法をなんとか見つけ出したいところです。
いろいろ調べてみると多分こんな感じの仕様ではないかと思いました。
- 「high traffic」エラーはBotを検知すると表示される可能性がある。
- Bot対策機能は、リリース直後の一定時間有効となる。
- リリース直後以外のリストックではBot対策機能が無効となるため、おそらく決済ページのbypassが可能。
次回はリクエスト型をもう少し改良し、いろいろなパターンで動作するようにして、さらに調査してみたいと思います。
コメント