クレカ支払いは、３Dセキュア認証が必須になっていました。
そのため、自動入力に対応しました。３Dセキュアが固定のパスワードのときのみ使用ください。
リクエスト種別の「開始時連発＋継続」ですが、複数のリクエストを行うことで３３％のところからの進みが遅くなっている現象が見られたので、機能自体を廃止しました。
どのくらい経過しないとディレイさせられてしまう仕様なのかは分かりませんが、本日最初に動作させたときは３３％でディレイになることはありませんでした。（動画では３３％で少しディレイがあります）
ということで、
ＢＯＴを動かすときは、その日は練習はしないで、本番一発で決めるようにするのがベストのようです。
BOTを使わないで、普通のブラウザで購入を行おうとしても、拒否画面が出るとの情報があったので、IPアドレスで弾いているようです。
Proxyを使うのも手ですが、Proxyがそもそも遅いと意味がないですが。。。
人気チケットは、混雑時にReCATPCHA を出すことがあるそうです。
販売側が出す出さないを決める事が出来るのか、ランダムで出るのかはこちらでは未確認の為分かりません。
情報お持ちの方はご連絡ください。
最近、Developer 用ブラウザに限り、Google ログインをできなくする処置が施行されたことで、Google のシステムを使ったサイトでは、如何に攻略するかを模索しています。
Google のシステムを導入する企業に大手はいません。それはやはり自社のシステムに他社の無償提供されたシステムを使う事を良しと思わないからでしょう。Google に何でもかんでも依存していたら、いずれはネット支配された世界になってしまいます。
体力に自信がない企業はサーバの強度増幅に費用を掛けられないのでGoogle に頼ることになるのでしょう。しかし、Google を100%信用している企業は無いと思います。
私自身、Google のサービスはよく利用していますが、攻略を諦めている訳ではないので、常に隙を伺っています。
2021/09/05追記
画像認証をたまたま見ることができたため、調査したところ、混雑している状況のときに最初にreCAPTCHA V3でチケットをカートに入れるのですが、同じページに戻された場合は、今度はreCAPTCHA V2で画像認証を出してきて、それを突破してようやく支払い画面に進みます。
ブラウザはChromeで行ったため、Googleにログインした状態でも画像認証が出てきたので、強度は一番強いものにしているようです。
2021/09/06追記
第１段階として、reCAPTCHA V3が出ている場合のみ自動突破を試みる対応をします。
その後にreCAPTCHA V2が出たときは、ブラウザに表示するようにします。
本来であれば、reCAPTCHA V2用に備えて、動作開始前に第３者認証を動かしておいて、reCAPTCHA V3後にreCAPTCHA V2が出ても自動突破するようにしたいのですが、当方は何のチケットが人気があるのかが判断できないために、こちらで動作確認が出来ないため、少しずつ対応をしていき、ログで判断していきたいと思います。
人気になるチケット情報とFeedbackがあると嬉しいです。
2021/09/07追記
reCAPTCHA V3対策をリリースしました。LivePocket 自動購入を起動するとアップデートされます。
reCAPTCHA V3からV2に変化した場合はまだ対応出来てないのでご了承ください。
2021/09/09追記
reCAPTCHA V3が出る確率をログから判断すると３％以下でした。当方は何が人気のチケットかは分からないので、３日間の中で混み合うチケットは少なかったのかもしれません。
数は少ないながらreCAPTCHA V3が出現したケースは、必ずreCAPTCHA V2に遷移していたので、第３者認証を導入することにします。
2captchaとanti-captchaを導入予定なので、各サイトの残高を確認しておいてください。
2021/09/12追記
reCAPTCHA V2に対応しました。
混雑が予想される、或いは以前出たことがあるチケットについては、第３者認証の設定を行ってください。
以下は、とある新規ユーザと何度かやり取りしていて、結果が出せたときのメールです。
結果が出せたのはこちらとしても嬉しいし、今後も使ってもらえるだろうと予感させてくれるものなので、こちらもモチベーションアップします。
メジャーではないけれど、応援している人が必ず存在していて、その手助けができていると思うと、同じようなチケットサイトを対応したくなりました。
AIOβ版を完成した後になりますが、TIGETの対応をしていこうと思います。
Yahoo!ショッピングもそうだが、LivePocketについてもお行儀よく作りすぎていた。まだ削れるところがあったのに、盲点だった。Yahoo!ショッピングについてはβ版として関係者内において既にリリースしているが、楽天BOTのようにサーバとの時刻差を出すようにして欲しいという要望があり、その対応をしている最中。LivePocketも今週中には新バージョンをリリース予定だ。
交渉役の営業担当がビジネスパートナーとして参加したことで、やることが一気に増えてきた。
足場が固まってきつつある状況を考えると、どうしても専業でやりたい気持ちが強くなる。
The法人化。
やりたい。
昔から会社経営をしてみたい夢があったので、それが現実味を帯びてきていることは確かだが、反対勢力をどう説得するかが鍵となる。
嫁だ。
安定した収入でいて欲しいという理由から、尽く反対されてしまう。先がどうなるかなんて誰だって分からないはずだが、それでも安定を選ぶ理由は、２人の子供を育てる母親としての希望であることは百も承知だ。
実に悩ましい問題である。BOT開発が専業でできれば、もっと精力的に開発に専念できることで、より多くのサイトを対応できるようになる。いろんな方からの要望にもっと答えられるようになる。
わたしゃ、この方を存じ上げませんが。。。
本日もまた人気のチケット情報をユーザより頂き、試しに購入してみました。
前回と同様、３０秒ちょい前でのゲットとなりました。
どうも家の環境では、混雑時のチケットはこれが限界のような気がしています。
あとは環境を変えるしか早くなる方法はありません。
２枚ゲットしたので、欲しい方いらっしゃいましたらメールにてご連絡ください！
LivePocketを修正したので、試し動作しました。
ユーザから人気があるものをチョイスして頂き、参戦しました。
ログイン状態が解除されているという謎のエラーが出ていますが、ちゃんととれていました。余裕でゲットでした。
両日ともに１枚のみですが、欲しい方いましたら、メールにて連絡ください。
（ローチケは番号で発券できますよね？？）
他ユーザは、１１秒程度でゲットしていました。
なんでこんなに差が出る？？監視のやり方が間違っている？！
HTTPプロトコルの応答ステータスにおいて、Service Unavailableというのがあります。
以下は、 https://developer.mozilla.org/ja/docs/Web/HTTP/Status/503 を引用しています。
HyperText Transfer Protocol (HTTP) の
503 Service Unavailableサーバーエラーレスポンスコードで、サーバーがリクエストを処理する準備ができていないことを示します。
一般的な原因は、サーバーがメンテナンス中のために停止していることや、過負荷状態になっていることです。このレスポンスは、一時的な条件に使用する必要があり、Retry-AfterHTTP ヘッダーには、もし可能であれば、サービスの復旧に要する予想時間を含めるべきです。
メモ: このレスポンスと共に、問題を分かりやすく説明するページを送信する必要があります。
503 のステータスはしばしば一時的な状態であり、レスポンスは頻繁にキャッシュされるべきではないため、このレスポンスと共に送信されるキャッシュ関連のヘッダーは注意する必要があります。
最近関わった３つのサーバの全てが混雑時に５０３を返しています。楽天チケット、LivePocket、ASICS Tigerです。
上記３つのサーバは、発売時刻と同時に５０３のアクセス制限となるのですが、一定時間が経過すると、アクセス制限が解除されて、通常のアクセスができるようになります。
アクセス制限が掛かると、恐らく一律制限が掛かるため、持久戦の状態になります。サーバが処理することが可能なアクセス数になるまで制限をかけています。アクセス数がしきい値を下回ると、アクセス制限が解除されるという感じです。（あくまで私感です。）
このような仕様にするメリットは、比較的能力が低いサーバでも運用が可能になるという点があります。ユーザビリティは最悪ですけどね！！
週末はASICS Tigerのコラボ商品に参戦していました。
初めての参戦ということもあって、サーバの勝手が分かっておらず、リトライ処理が不十分だったのですが、ユーザがそれを補うマクロを作ってリストックしていましたｗｗｗ
ものの５分ぐらいで対応していて、いろんな状況に臨機応変に対応するところが流石です。
ただし、動画のような処理は、本来であればBOTが搭載すべき機能のため、今後の改善・対策内容に盛り込みます。
ECサイトやチケット販売サイトにおいて、以下のような仕様があります。
１．ログインセッション時間が存在する
２．新商品（新発売チケット）が出るまで、監視間隔毎にアクセスする
３．BOTの背景色は、黄緑は自動ログイン動作に入ったことを知らせる、黄色は動作開始、青は目的の商品が出現したため、購入動作に入ったという意味である
１については、購入前にログインすることにより、購入中のログイン処理を省くことができるため、より早く購入手続きを行うことができます。
対応できているBOTについては、ECサイトの標準的な仕様として１０分程度のログインセッションがあるため、タイマー動作時に限り、購入動作開始時刻の１０分前から自動でログインする仕組みがあります。
これを使う場合の注意点としては、BOTの開始ボタンを押す前にログインボタンを押さないことです。
チケットぴあやイープラスなどのチケット販売サイトは、購入時のログインセッションという概念がないので、自動ログイン機能はありません。
一方で、LivePocketは、ログインセッションがあることが判明しましたので、近いうちに自動ログイン機能を追加します。
２については、新商品（新発売チケット）が出現するまで、アクセスし続ける機能です。但しアクセスし続けるとサーバからIPBANされる可能性が高まるため、監視間隔毎のアクセスを行うような仕組みとなっています。
２はブラウザで行う場合のF5を一定間隔で押す行為を自動で行っている感じです。
２の機能は、BOTの左下のステータス表示部分において、時刻が逐一変わっていることで視覚的に確認できます。
３についても時々問い合わせがあるため、明記しました。
LivePocket自動購入は、これまでは１週間ライセンスのみを扱っていましたが、半永久版が欲しいという意見を頂いたため、別途用意しました。機能は、１週間ライセンスも半永久ライセンスも同じものです。
ASICS Tiger自動購入をリリースしました。明日の人気商品で初動作となります。結果は追って報告する予定です。
只今、Yahoo!ショッピング 自動購入を制作しています。完成は今月中を予定しています。βテスト時に参加したい方は、メールにて問い合わせください。
2019/08/20 追記
Yahoo!ショッピング自動購入のβテスト利用者の受付を終了しました。
参加表明頂いた方々には、完成した際に折り返し連絡いたします。
Chromeの更新はとても早い。当BOTのブラウザバージョンは、最新Chromeより１年以上前のバージョンを使っているため、Chromeと同等にするためには、自前でソースコードをビルドするしかない。
１年前のソースコードと最新のソースコードをマージするだけでもかなりの労力であり、無償アップグレードにする気は無い。しかし、Chromeの更新が多いので、それと同等のアップグレード料金を設定することを考えただけでも頭が痛い。
ブラウザを更新する必要があるBOTは、そう多くないのだが、これを対応することがとても重要な要素なので、何とかしたい。
現状は、ビルド手順もまだ確立していない状態で、１ヶ月前から試行錯誤中である。なにせ膨大なソースコードのビルドをするだけでも１日潰れてしまうので、かなり効率が悪い。ここだけの話、本業の仕事中でもこのことをやっているぐらい、今は時間が欲しい。
この前のadidasは、発売時間を変則的にしてきたことで全てが狂った。そもそも１０時以外の時間のことは考えてなかった。デフォルトの時間じゃ駄目なことは知っていたし、今回は惨敗だった。次回のことを踏まえて、デフォルト値と最小値を変更するようにアップデートする予定だ。
今頃になって、LivePocketが売れるようになってきた。作ったあと全く売れなかったので、騙されたのかと思っていたが、そういうことではなかったようだ。
ログを見る限り、かなりエキサイティングな戦いがあるようで、購入中に弾かれる動きがあることが分かった。こういう場合はどうしたらよいかというのが、２０サイト以上対応している経験からか、迷うことなく動作確認もしないで対応できるようになった。
同じ動きのサイトは１つも無いが、http ver1.1の仕様である限り、ある程度の型があるので、作成時間も２年前の1/3程度で作れるようになっている。先日も個別な依頼があり、とあるBOTを作成した。とても変わった仕様だったので面白そうだと思い引き受けた。
これは作りたい！！と思うサイトが無くなってしまった。SNKRSは先着じゃないから作らないので悪しからず。E-FLASHも販売数が少なすぎてしらけるので、発売するか迷い中。BAPEは最近音沙汰ないので動作確認ができない。
先着で発売するECサイトで作って欲しいところはあるかい？
