クレカ支払いは、３Dセキュア認証が必須になっていました。
そのため、自動入力に対応しました。３Dセキュアが固定のパスワードのときのみ使用ください。
リクエスト種別の「開始時連発＋継続」ですが、複数のリクエストを行うことで３３％のところからの進みが遅くなっている現象が見られたので、機能自体を廃止しました。
どのくらい経過しないとディレイさせられてしまう仕様なのかは分かりませんが、本日最初に動作させたときは３３％でディレイになることはありませんでした。（動画では３３％で少しディレイがあります）
ということで、
ＢＯＴを動かすときは、その日は練習はしないで、本番一発で決めるようにするのがベストのようです。
当社が使用しているフレームワークに、新しい暗号化ライブラリの移植が成功しました。
移植に成功しても、KAGOYA CLOUD VPSで動かないと意味がないので早速動作確認をしました。
リモートデスクトップのIPアドレスがKAGOYA CLOUD VPSのものであることを以下の２つの画像で証明しています。現在リリースしているインストーラでは、ライセンス認証が出来なかったのですが、新しいフレームワークでは、ライセンス登録ができるようになりました。
AWSでも動かないようなので、来週中には全てのアプリケーション分を用意したいと思います。
今回移植した暗号化ライブラリは、既存の暗号化ライブラリよりも軽量という謳い文句がありますが、軽量≒高速（軽量だから高速である）というわけでもなく、以前のものも残す方が良いのか悩みますが、利用する側としては、利用できることの方が重要だと思うので、一気に変えていきます。
あれやこれややっていたので追記が遅れたのだが、実は２日後には以下の回答が来ていた。
この言い分は、Windows OSについてはカスタマイズは一切していないよ！ということだ。
Windows OSのNDIS中間ドライバやもっと下位のドライバでブロックすることもできそうだが、上記のことがあるため、ルータでブロックしていることはほぼ間違いないだろう。
このようなケースが他にも考えられるため、自分的には意地でもOpenSSL以外の暗号化スイートを使用したいと考えていて、今はそこに全力投球している。
今は良さげな暗号化スイートをフレームワークに移植することを行っているのだが、その暗号化スイートはOpenSSL ver 1系に合わせたI/Fを用意している一方で、フレームワークはOpenSSL ver 3系のI/Fになっているため、こちらで合わせ込みをしなければならず、予想外に時間が掛かりそうな状況になっている。
ぴあの座席指定機能を追加して欲しいとか、TicketBookに対応して欲しいとか要望を頂いているのは認識しているが、直ぐの実現は難しい。
TicketBookは、去年の年末にサイト側が刷新されたので、アップデートしようとしていたのだが、ブラウザではなく通信データでリストック監視を行った途端にBOTだと判断されてカートにチケットが入らなくなる。これについて色々悩んでいたら風邪を引いてしまい、モチベーションが落ちてしまってほったらかし状態になっていた。
当社BOTは必ずブラウザと共存した作りにしているので、ブラウザの自動操作も駆使することで対応は可能だったとは思うのだが、モチベーションが下がってしまっては元も後もない。
脈絡とは全然関係無いのだが、問い合わせをもらうときに、「いつもお世話になっております」という文言が最初に入ることが多くなった。
実はこれ、俺からするとかなり違和感がある。
サブスクの商品であればまだ理解はできるが、売り切りの商品についてこれを言われても、契約書を交わしている訳でも無いわけで、こちらからすれば赤の他人から言われても違和感しかない。カスタマーサポートが存在する企業であれば、そこが一次受付するから、開発部署には問題の内容ぐらいしか届いてこないのが普通なのだが、当社は俺しかいないので仕方ないのかもしれないが、変えていきたい。
問題提起をしてくれるのはありがたい反面、只々動かないとしか書かれていると、これで何を判断しろって言うんだ？！と思う。ログや画面キャプチャーなどの証拠を提示してくれれば、こちらのことも考えてくれていると思える。
Google DriveやOne Driveにログや画面キャプチャーをアップロードさせておいて、そのリンクを問い合わせフォームに貼り付けてくれれば助かります。Driveにアップロードしたログは共有状態にしておくことを忘れずに。
BOTを使う場合、自分の家の環境でIPBANになったら不便になるので、ProxyIPを使うか、VPSを使う選択をする場合も多いと思う。
最近、ユーザからインストーラが動かないという連絡があった。以前もこの問い合わせがあったときは、ITリテラシーが無いのだろうと決めつけてしまい、BOT利用自体をお断りすることがあったが、今回は詳細な事象を話してもらえたため、原因追及のために私自身が調査を行った。
当社のインストーラは２種類存在しており、インストーラ内に全てのモジュールを詰め込んであるものと、インストーラを起動すると、インターネットからモジュールをダウンロードするものがある。今回の事象は後者の方で、モジュールがダウンロードできないので、インストーラを動かすことができなかった。
最初は、ファイヤーウォールや受信の規則を弄れば良いのではと考えていたのだが、そこらを弄っても全然改善されない。
まず何が原因なのかを調べるため、VPSにWiresharkを入れて、通信の状況を監視したところ、そもそもデータがサーバに届いていないことが分かった。具体的には、サーバには送っているが、KAGOYAのLAN内で戻されていた。恐らくルータにブロックフィルターを仕掛けているのだろうと思い、問題の切り分けをするために、HTTP POSTデータ送信を行うだけのアプリを作り、暗号化ライブラリを変えて通信できるか確かめた。
当社が使っている暗号化ライブラリはOpenSSLを採用しており、インストーラもOpenSSLを使用している。これはOpenSourceであり且つアップデートが頻繁に行われているため、信頼性の高いものである。こちらを使った場合は、サーバとの通信が行えなかった。
もう一つはEdgeの暗号化ライブラリを使ったHTTP POSTデータ送信を使用したところ、問題無くサーバとの通信ができた。
暗号化ライブラリが関係しているのは、下記の第５層に位置している。恐らくKAGOYA VPSでは、LAN内のルータにて第５層のペイロードを見て、OpenSSLだと分かる何かで判断して、ブロックしているのだと思う。
BOTが扱っているのは第７層だが、ここは暗号化ライブラリによりデータが暗号化されているのでチェックすることが出来ない。そこでBOTが使用している暗号化ライブラリに着目して、BOT利用者を弾き出そうとしたという訳だ。
いつから使えなくなっているのかは分からない。少なくとも１回目の使えない報告があったのが2023/3/25なので、それより前から使えなくなっていたということだろう。
この対処の仕方が、一般的に考えてあり得ない対応だと思ったので、当方からKAGOYAに以下のように問い合わせてみた。
土日祝を除いた３営業日と考えると、18時は営業時間外なので11/14（火）までに連絡があるのか待ってみようと思う。
今回発覚した暗号化ライブラリ特有のペイロードでブロックしているということが分かり、こういう技術は、BOT対策として他でも行っているに違いない。
ブラウザと同じデータを送っているのに、処理でHTTP通信を行うとサーバ側で弾かれる理由の１つにこの件が該当するのだと思うと、もっと早く調べておけば良かったと少し後悔した。
当社BOTは全てOpenSSLを使用しているため、他の暗号化ライブラリに変更しようと実際に動き始めている。
サーバ運営側はBOT利用者を追い払いたいと思うだろうが、私はBOT利用者を推進する側なので、今回のことは正直むかついた。
前回の便利ツール（Androidアプリ）と連携する機能を、チケットぴあ自動購入に追加しました。
使用するには、最新のインストーラをインストールする必要があります。
ヘルプメニューの「MQTT Settings」を選択すると、以下の画面が表示されます。
MQTT Brokerに接続のための情報を設定後、Connectボタン押下で、接続されます。
次に、Topicを指定します。指定後、TabキーでSubscribeボタンが有効になります。
Topicは、便利ツール（Androidアプリ）と同じにする必要があります。
試しに、Publish欄に、「tel:xxxxxxxxxxxx」（x=電話番号）を設定してPublishボタンを押下すると、便利ツールが起動状態であれば、その電話番号に発信することが確認できます。
以下は、チケットぴあ自動購入ツール自身も「tt」TopicをSubscribeしているため、送信したデータを受信しているのが分かります。
チケットぴあ自動購入の右側には、MQTTの状態が表示されており、以下の表示になっていれば、繋がった状態になります。この状態であれば、電話認証が表示されたときに、スマホと連携する動きになります。
座席指定のチケットを扱うのが初めてだったからか、対応する画面の量がいつもの倍以上あったため、予定外の時間を費やしてしまいました。
画面遷移の仕組みも、自分は今まで出会ったことが無い作りになっていて、最初はすんなり行けそうと思っていたのですが、なぜか最後の購入完了のところでサーバに弾かれてしまい、その理由が全く分からず、仕方なく通信とブラウザ遷移のハイブリット型と言ったらよいのか、とにかく今までの形とは異なるものが出来上がりました。
動作速度については、最速にはしておらず、失敗しない速度にしています。
最後の画面遷移は入力はしていません。裏でデータは全て取得済みのため、そのデータを足しているだけです。
当社の見解を以下に載せました。
https://zatturight.com/community/viewtopic.php?f=14&t=264
この便利ツール（Androidアプリ）は、v1.0.0ではYahoo!ショッピングのSMS認証で、スマホに受信された認証コードをBOTに連携するツールとして、Emperor AIOで使用するためにリリースしたものです。
名前は適当です。当初はGoogle Playに登録しようかと思い、分かりやすい名称ということで選んだものですが、当方の時間的余裕が全く無いので、Google Playからのインストールではない方法でインストールするやり方を採用しています。
野良アプリをインストールするやり方をググれば色々出てきます。
APK（Androidアプリ）は、https://zatturight.com/fastbot/products/detail/38 の下の方にダウンロードリンクがあります。
LAN環境以外でも利用できるようにするため、MQTTというプロトコルを使用することにしました。以下が便利ツールアプリ画面です。
便利ツールはMQTTのクライアント側で、サーバ（Broker）はPublic Freeなところを使用することを想定しています。
個人で使用する分には、有料になることがまず無い程のリソースが用意されている以下のサーバを使用することを前提に進めていきます。
https://www.emqx.com/ja/pricing
MQTTは、世界規格統一された通信プロトコルで、LINEやDiscordなどのチャットシステムで利用されています。
MQTTを簡単に説明すると、Publish アンド Subscribe モデルで動作するマシン間接続プロトコルです。
MQTT クライアントは、MQTT を使用して MQTT サーバーへのネットワーク接続を作成するプログラムまたはデバイスであり、 ブローカー とも呼ばれます。
通信が確立されると、クライアントはブローカーにメッセージを送信できるようになります。
他のクライアントは、クライアントから送信された特定のトピックに関する通知を購読できます。
Brokerとして今回利用させて頂くのが www.emqx.com 、SubscribeするだけのClientが便利ツールアプリ、PublishするだけのClientがチケットぴあ自動購入ツールとなります。
何をしたいのかというと、チケットぴあのログイン後にたまに電話認証になりますが、これを自動化したいというのが目的です。
Cloakでリストック監視を行っていると、１日に２～３回は遭遇します。手間でも認証を通しておけば、発生頻度は減ります（と思う）が、電話を掛けること自体が手間です。例え自動化させても、電話認証が出た段階で速度的に不利になることは間違いないので、電話認証が出たときは厳しいかもしれませんが、自動化によってストレスフリーになることをモチベーションとしています。
ただ残念なことに、便利ツールは着信時のときのように画面ロックを解除するような特別な権限は無いため、常に便利ツールを起動し続けなければPublisherからの通信データ（電話番号）を受け取ることができません。
常に起動し続けるためには、特殊な操作で開発者オプション画面をまず出して、スリープモードにしない設定にしたのち、常にUSB電源を繋げておく必要があります。開発者オプションの出し方は、ググれば出てきます。
スマホ側のセットアップが完了したら、次はBroker側の準備です。
https://cloud-intl.emqx.com/console/deployments/new
上記リンクから、無料開始ボタンを押して、アカウントを作ります。
個人情報を入力する欄がありますが、クレカは登録しなくても使用できます。
無料枠は個人利用としては使いきれない程の上限幅なのでクレカを登録する必要は無いでしょう。
アカウントを作成したら、ログインします。
https://cloud-intl.emqx.com/console/
Console画面に行くと、接続先が表示されているので、便利ツールの接続先に指定します。
左側の認証メニューから、ユーザを作成して、便利ツールのユーザとパスワードを指定します。
便利ツールアプリ側でConnectボタンを押して、接続されたら、動作確認をしてみましょう。
サーバ側Consoleメニューのオンラインデバッグを開きます。Connection Nameは適当で構いません。
Topicは、便利ツールのTopicと合わせる必要があります。tel:の後に電話番号を入れてPublishボタンを押してみてください。スマホが自動的に電話発信されたら成功です。
チケットぴあ自動購入ツールの対応後に続きを書きます。
リストック監視はいつ来るのか分からない点と、今回の様に、普段出ない画面がプレミアムチケットのときだけ出現するというのがあると対応が厄介だ。
以前からCloak対応して欲しいという要望があったのだが、先着で取れば良いのでは？と思っていたが、時代はそうじゃないことに今回初めて気づいた。
転売禁止の法律が出来てから、チケットは電子的なやり取りに変わっていたのは知っていたが、流通自体も変わっているのは知らなかった。。。
今回は長期にわたってリストックし続けるという性質があったお陰で、苦労はしたが結果は残せた。
Cloakの画面にチケットがあるのは新鮮だ。。。
１枚チケットでも２枚チケットでも対応しており、２枚目は、BOTの右側に個人情報を入れておけばOK。
残件として、電話認証を自動化するAndroid用のアプリの開発が残っている。Google Playには置かずに、ローカルからインストールする形にします。
※iPhone用は作りません
次は、Global interparkを対応します。
Pythonはちょっと弄りたいときに手軽に作れるのが気持ち良い！！
エルメスの商品はバカみたいに高額だと思うが、欲しい人からすると喉から手が出るほど欲しいもののようで、欲とは？という感覚になった話をしたい。
エルメスオンラインは、先着の商品を扱っており、早い者勝ちではあるものの、グローバルIPアドレスのブロックが世界一激しいところでもある。それだけみんなが狙っているということなのだが、つい最近ユーザに成り掛けた人から色々な話を聞いて、なんか凄いことになっているなぁと思うことがあったので、隠すようなことでもないので、ダラダラ書いていく。
日本は円安真っ只中で、世界から見てもかなり割安感があり、エルメスなどのハイブランド商品も他国と比べれば圧倒的に安いのだそう。それをビジネスにしようとしているのが中国人だ。
１つ目は、人気商品がリストックされたらそれを通知することを商売にしている輩。サブスク契約で月額10,000～15,000円程度らしいが、ラッキーじゃなければまず取れないだろう。それでも通知が来てカートに入っただけでも夢見るのだそうだ。「次は取れるのではなかろうか！！」と。
２つ目は、自分たちで取ったものをTwitterで自慢しつつ、かなりの手数料を取って売り捌く輩。なんでも輩にはいくつかの組織が存在していて、序列によってその商品の色を取ってよい輩とダメな輩という括りがあるらしい。
インターネットという仕組みは、世界共通の仕様に基づいており、速度の違いはあれど誰がやっても同じ仕組みを使っていることに変わりはなく、ショートカットなどというものも存在しない。
あそこは良く取れるというものがあるとしたら、品質の良い機器や通信環境を使っている程度である。
エルメスを高く売り捌けるなら、私も本業にしたいぐらいだが、どの色が高く売れるのかなんて分かる訳ないし、そもそもハイブランドに興味が無いので、途中で飽きてしまいそうだし、モチベーションも下がってしまいそうだ。例え取れたとしても、取れるまでの経費を考えると、日本で売るのは赤字にしかならなさそうだ。
ウィルスバスターのようなウィルスチェックソフトウェアは、本来ならWindowsのチェック機構で十分なはずなのだが、未だに年間契約をしている人がいるのにも驚かされる。情弱な人たちをカモにするビジネスモデルは、情弱な日本人をターゲットにしたモデルだと言える。
今やITは生活に無くてはならないものだからこそ、知識を付けなければ日本の衰退は加速していく一方だと思う。IT技術者が学ぶ基礎知識の一部を学校教育でも必須科目にする必要があるんじゃないか？
