ISBN-10とASINの不一致でリンク切れ

3月ぐらいからISBN10でamazonの情報が取れないだけでなくリンクも出来ない状態が発生してました。
なにを言ってるのかと言うとamazonは元々本屋サイトなのでISBN10をamazonoの商品番号ASINと一致しているのでURL構成が「https://www.amazon.co.jp/dp/{ISBN10}」とできてましたがごく一部の商品だけISBN10とASINが一致しないため「商品が見つかりません」となってしまってました。
まだその頃は「出版社の人が登録す際に失敗したのかな？」と見つけた数十件を転送したり検索するようにする仕組みを作ってリンク切れはしないようにしていた。
6月末まではサーバーの移転とその前のデータ整理で気づくのが遅れてしまいました。
被害の大きさに気づいたのはカバー画像を拾うスクリプトが10件ずつ調査するのですが一部の商品を検索すると残りの商品も共倒れになり取得に失敗扱いにされてしまう事象が発生しその原因の商品がISBN10とASINが一致しない商品だったので調べた所7月8月のコミックや文庫の発売日データの1割ぐらい（体感）がISBN10とASINが一致しなくなっていました。

ご迷惑をおかけして申し訳ございません。
ひとまず今月まで調査できたのはASINを書き換えてリンクするようにしました。
ここ数ヶ月で急激にISBN-10とASINの互換性が無い書籍が増えてきた理由はよくわからないけどamazonは以前から一致させないようにする事は示唆してたみたいなので、マイリリースもISBN-10での管理が考え直す事になりそうです。

またサーバーを移転しました

coreサーバー（間借り）
↓
ロリポップ
↓
ヘムテル
↓
CPI
↓
さくらのVPS
↓
XサーバーVPS

と渡り歩いて来ました。
マイリリースはソコソコ負荷が高かったりしたので単にスペックアップが必要で引っ越してきたのもあるのですがVPSになってからはOSの更新で必然的に数年に一度のタイミングで入れ替える必要があるので引っ越しのタイミングがやってくる。
今までは一月かぶりで別のさくらのVPSを申し込んで引っ越し作業していたのですがAIに聞いたらXサーバーの方が安くて速いらしいので引っ越す事にした。

さくらのVPS 仮想CPU 4Core/メモリー 4GB/SSD 200GB 月額3,227円
XサーバーVPS 仮想CPU 4Core/メモリー 6GB/NVMe SSD 150GB 月額1,700円

簡単なスペックでも安くて高スペックですが回線も太いらしい。

今回は更にメールをVPSから切り離した。昔はお問い合わせのメールとかサーバーを跨ぐとそれだけリスクがあると聞いていたがメール間もSSLが当たり前で、よくわからないVPSよりもレンタルサーバーとかメール配信サーバーのほうが信頼される（迷惑メールに入りづらい）らしい。
正直VPSを運用する一番面倒なのはメールサーバーの設置やセキュリティ対策だったので外部化できるのはすごく助かる。
外部のメールサーバーは基本はコアサーバーのを使ってお問い合わせとかはSMTP2GOを使っています。

DNSもCloudflareに置いてるので外部化だらけになってしまって障害の可能性が増えそうにも感じるが専門家に任せないと危険な世の中とも言える。

さくらVPSではSELinuxがOFFの状態だがXサーバーVPSはONがデフォルトなので要所要所で躓いたがAIに聞けば答えてくれるのでなんとかなった。
もしAIが無かったらOFFにしてると思う

XサーバーVPSは管理画面もモダンで迷うことが少ないしレスポンスも良くなった気がする（プラシーボかもしれない）

悪質Botとの戦いは続く

最近GoogleAnalyticsにて今までほぼゼロだった中国の方が急増した。
実際は米国からすごい量のクローラーが来てるがGoogleAnalytics上では除外されるのだが今回の中国のクローラーは自然で除外しきれないということかと思う。
言語やIPアドレス等で調べても特に中国人が多いようには見えないが発売日の検索機能を叩いてるようなのでクローラーに検索結果はクロールしないよにと伝えたが、悪質Botは無視してクロールしてくるので悪質Botっぽい怪しいユーザーがリファラー無しで検索したらブロックするようにしました。
それでも攻撃の手は激しい攻撃者のUAを見るとどうもかなり古いUAをランダムに出してるようなので悪質Botっぽい怪しいユーザーが古いブラウザ使ってる場合ブロックするようにしました。
誤って普通の閲覧者を排除してしまう可能性もあるのでブロックは極力したくなかったのですが、放置できるレベルを超えた状態が続くのでブロックしる事になりました。
万一閲覧に問題がある場合はお知らせいただけると助かります。

AmazonのAPI移行

昨年末amazonのAPIに改定のお知らせがありました。（Googleで翻訳してます）

PAAPI、V1移行を提供 - 期限延長
商品広告APIのOffers V1の廃止期限を2026年1月31日まで延長しました。PAAPI Offers V2にアクセスするには、 1月30日までに新しいCreators APIエンドポイントに切り替えてください。新しいCreators APIエンドポイントへの移行手順については、Associates CentralのCreators APIページをご覧ください。

数年前の改定（PA-API5）は提供される情報が量的質的に低下した改悪でしたが
今回は「新しい方式への移行が進まないので古い方を少しずつ使えなくしますよ」という感じのアナウンスがされたので調べてみるとどうやら今までのAmazon PA-APIがCreaters APIというのになるらしい。
テストでいじってるとちょいちょい制限が発生しましたPAAPIのように詳しい情報が出ていないので具体的な制限が分からないので金額が表示されないとか表示が遅いとか何かしらのご迷惑をおかけするかもしれません。

Creators APIは情報がまだ少ないですがリファレンスは用意されてましたし、認証が一般的な方式へ切り替わったので分かりやすくはなっていました。

https://affiliate.amazon.co.jp/creatorsapi/docs/en-us/introduction

私の場合はお知らせをPAAPIからOffers（価格や在庫の情報）が除外されOffers専用のAPIができたと勘違いしてたので2つのAPIを叩くややこしいシステムを途中まで作ってしまったのでとても時間がかかってしまいましたが、マイリリースもCreators APIに対応しました。

ログインの維持方法を変更しました。

マイリリースではセッション方式とクッキー方式でログインを維持していました。
最初にマイリリースの会員システムを作成した10年近く前にログインの維持方法を調べ、当時のベストプラクティス的なログイン方法を参考にはしてたのですがセキュリティ的に「ホンマに大丈夫？」って感じのものしか見つけられなかったので独自の方法でセキュリティを補完したような形でログイン維持をしていました。
ただ、セッション方式だと維持時間が短くスマホだと閉じると切れてしまうので、
「次回から入力を省略」をチェックしてクッキーにランダムな文字を入れたりしてログイン時間を増やす方法を追加しました。
ただ、独自のアルゴリズムは不安なので10日に限定していた。

それから年月が経ち、世間的にはフィッシングやキーロガーやショルダーサーフィンなどで「ログインする時が危険」みたいな風潮になってきて、最近は色々なサイトでログインを維持する時間が長くなった気がしてAIに聞くとマイリリースレベルの規模だとJWTというのが一般的でこれならそこそこログインを延ばしても安全らしい。

リフレッシュトークンの考え方的には独自で考えたものと似た考え方なので理解できたけどセッション（JWTの署名検証）だけでログイン維持させるのが大丈夫？って感じたけどChatGPTと問答して安全性が理解できたので、ログイン方法をJWTな方式にしてログイン維持を30日にしました。

あとパスワードの保存も今までsha1に独自のアルゴリズムを織り交ぜたものをハッシュ値にしてたけどAIのコードレビューでは独自アルゴリズムの部分は無視してsha1は危険といわれるのでAIに言われるがままモダンなハッシュ値に変更しました。
（パスワードログイン時に新しいハッシュ化に変更されます。）

BotにはCloudflare

前回の謎のbotの大量アクセス問題からなんやかんやPHPやサーバー設定でできる範囲で対策してましたが減りはしたものの油断するとまたやってくるとういう状態がつづいてたので Cloudflareを召還することにしました。

Cloudflareは過去に何度か落ちてるし以前別サイトでCloudflareのCDNを使ってて見れない状態になった事もあり個人的にはCloudflareはあまり入れたくは無かったのですが背に腹は替えらません。
（導入して数日後に案の定落ちたりしましたが今回はキャッシュに使ってる訳ではないので影響は無かったようにみえます。）
導入してからログを見ると怪しいbotはみるみる減ってめでたしめでたしと思ったのもつかの間。
実はIPアドレスがCloudflareのものに置き換わってる問題が発生して、マイリリースではセキュリティ的にIPが変わったらログアウトする仕組みにしていたのでログインの維持すらできない状態になっていました。
ご迷惑をおかけして申し訳ございませんでした。
こういったIPを書き換えられるサービスにもサーバー側は対策（remoteip モジュール）が用意されていて、このモジュールを使うことでIPアドレスを戻せました。

ちなみにIPの書き換え問題で怪しいBotがいなくなったと勘違いしたわけでは無く本当に怪しいBotを排除してくれたようです。ただこのIPを置き換えられる現象があるとレンタルサーバーとかでは使いづらい気がする。（もちろん、Cloudflareに対応してるレンタルサーバーとかでは勝手に戻す作業も組み込まれてる場合もあります）

犯人はアリババにいる？

最近amazonのapiの帯域制限が厳しかったのですが「セールの余波かな」ぐらいに思ってたのですがセールが終わってしばらくしても一向に改善されないのでログを調べて見たらbotが大量に沸いていてそのせいでamazon様から制限がかかってたようだ。

ログをざっと見てるとHTTPの方にBLEXBotが検索し続けてる状態だったのでココへのアクセスをブロックした。ただ検索するだけだとamazon様に負荷はかからないので関係は無い。

そもそもマイリリースの商品情報ページはASINを指定すると無限に生成されるので基本的にクロールされないようにしてるしブロックなどの対応は厳しめにしている。
（robots.txtを守ってくれればブロックする必要は無いのですが・・・）
ひとまず網を張って（プログラム的にブロックを通過してるログを収集するスクリプトを書いて調査して）みたら30分ぐらいで7500件ほどのアクセスがあった。
UserAgentは下記のように一般的にブラウザを模してるが
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.43
そしてその多くがIPアドレスが「47.79.」または「47.82.」で始まるものだったので調べて見たら
「Alibaba (US) Technology Co., Ltd. 」でシンガポールのISPという事だった。
読み解くと「中国企業のアリババがアメリカ法人でシンガポールのプロバイダーを経営してる所のユーザーがbot攻撃をしてる」という感じ？

プロバイダーという事で普通のユーザーもいるかもしれないのでどうしようかと思い、
IPアドレスの一覧をChatGPTに投げたら下記の様にごっそりブロックするように賜ったのでブロックしました。

Require not ip 47.79.0.0/16
Require not ip 47.82.0.0/16

先のUserAgentもChatGPTに確認したところMicrosoft Edge（Chromiumベース）バージョン 114で2023年6月2日製のもので
「一般ユーザーのブラウザがこのバージョンのままである可能性は低く、
自動アップデートを無効にしているか、ボット・クローラーの偽装の可能性も考えられます。」
との事だったのでブロックする事にしました。

ブロックすると数時間後にはVPS（なぜVPNでなくVPS？）を使って分散してきたのでVPSを排除した。

さらに数時間後にはネットワーク会社が特定できないIPアドレスにを分散化させてアクセスして来たのでそれらを排除して今のところ落ち着いてきた。

数十個のIPアドレスを使って、あくまで一つのIPアドレスあたりは10秒に1回の頻度とかなのでDDOSとかの対策をくぐり抜けてくるのがいやらしい。

とりあえずゲスト（非会員）のアクセスではamazonから最新の情報を取得する仕組みを抑止する事にしamazon様に迷惑をかけないようにしました。