Alicia
投稿の際は下記の情報をお書き添えください。
-------------------------------------------
WordPress のバージョン：（例 6.8.2）
Welcart のバージョン：（例 2.11.20）
PHP のバージョン：（例 8.2）
Welcart専用の拡張プラグインとバージョン：（例 DL Seller 3.5.8、SKU Select 1.4.7）
ご利用の親テーマとバージョン :（例 Welcart Basic 1.8.7）
ご利用の子テーマとバージョン :（例 Welcart Beldad 1.5.5）
利用している決済モジュール：
症状を確認したブラウザ：
サーバー【重要】：（会社名、サービス名）
--------------------------------------------
フォーラムへの返信
-
投稿
-
皆様
情報提供に感謝いたします。
どうやら、Google reCAPTCHA v3 もメール認証も不具合があるわけでもないのに突破されてるようですね。
reCAPTCHA v3 は、その仕組み自体がブラックボックスになっておりますので、どういう方法ですり抜けたのかもわかりません。
スコア（閾値）も０．５以上ですし、上げすぎるとカゴ落ちリスクが高まるだけに及び腰になるのも無理もありません。私も素人ですので間違いがあると思いますが、いくつか気になる点がありまして、可能性として一つの実験的な考察をここに残しておこうと思います。フォーラムご利用の方からのご意見がいただけると嬉しいです。
reCAPTCHA v3 のGoogle側のスコアの精度について、各サイトで結構バラツキがあるのではないかと思っています。これによって、脆弱なサイトと強固なサイトに分かれているのではないかと怪しんでいます。
多くのWelcart ユーザーは、お問い合わせフォームとして推奨されている Contact Form 7 をお使いだと思います。そして、Contact Form 7 にも reCAPTCHA v3 が利用できるようになっていて併用されているのではないかと思います。
reCAPTCHA v3 のバッヂはGoogleに認められている方法で普段非表示にしているのですが、これを表示するように戻して、自分のサイトをチェックすると、ほぼ全てのページでバッヂが表示されます。Contact Form 7 の作者は、このことに関して丁寧に説明されていて、Googleの公式では、出来るだけ多くのページで reCAPTCHA v3 を読み込ませることが精度向上のために望ましい旨述べられていると、記されています。つまりフォームのないページでの訪問者が実際に辿った動線データもボットと人間を区別する重要な要素となりうるということになります。
一方、試しに Contact Form 7 を無効化してキャッシュをクリアすると、Welcart が reCAPTCHA v3 を読み込ませているページにのみバッヂが表示されるようになるのですが、ログインページやカート遷移中のページなど一部に限定されています。これは、Google が提唱する利用方法ではないのかもしれません。だからと言って、スコアの精度が悪いとは言い切れないのですが、可能性としてはあり得る話ではないかと思っております。
Contact Form 7 のユーザーでも、お問い合わせフォーム以外のページに読み込ませるとサイトが重くなるので、「plugin load filter」などのプラグインで読み込むのを制限している人もいるようです。
そこで、ひとつの可能性として、Google reCAPTCHA v3 の運用上の理想の環境作りという視点でできることはないかと、二つ考えました。
一つは、単純に、Welcart がGoogle reCAPTCHA v3 を読み込ませるページの範囲を拡張すること。
もう一つは、Contact Form 7 と Welcart で reCAPTCHA v3 を共同利用できないかということです。共同利用については既に実行されているケースもあるのではないかと思います。
私はこれまで、Contact Form 7 と Welcart で別々の reCAPTCHAキーを利用してきました。
ここ数年、reCAPTCHA v3 の誤判定に悩まされていまして、試行錯誤している最中なのですが、reCAPTCHAキーを一つにまとめてしまえば、サイト全体としてのスコアの精度が上がるのではないかと予想しています。スコアの精度が目に見えるわけでもないので立証できないのですが、特に反証がないのであればやってみる価値はあるかもしれません。まとめてしまえば、結果的に、Welcart も訪問者が実際に辿った動線データを全てのページから取得できるようになるのではないかと考えます。（ここは、全くの素人考えなので、自信はありません。）
そうすることで、執拗に不正にユーザー登録ばかりを繰り返そうとするのを防いでくれるようになるのではないかと期待しています。一つにまとめるとデメリットもあります。このデメリットゆえにこれまで別々の reCAPTCHAキー を利用していたのですが、突破されるより全然良いと思いますので、実験結果によっては、今後考えを改める必要が出てくるのかもしれません。
以下は、Gemini に聞いてみた結果です。
Google reCAPTCHA v3 において、reCAPTCHA のキーは、プラグイン毎に分ける方が良いのか、共通のreCAPTCHA のキーを使用する方が良いのか、どちらですか？
回答案を表示
Google reCAPTCHA v3 のキーについて：プラグイン毎と共通のどちらがよいのか
Google reCAPTCHA v3 のキーをプラグイン毎に分けるか、共通のキーを使用するかは、サイトの規模、セキュリティ要件、管理のしやすさなど、複数の要素を考慮して決定する必要があります。【プラグイン毎にキーを分ける場合のメリット・デメリット】
メリット:
セキュリティの強化: 各プラグインのトラフィックを個別に監視できるため、特定のプラグインを狙った攻撃をより早期に検知できます。
柔軟性: プラグインごとに異なるスコアリングを設定できるため、よりきめ細かい制御が可能になります。
トラブルシューティングの容易化: 問題が発生した場合、原因を特定しやすいです。デメリット:
管理の煩雑化: 複数のキーを管理する必要があり、手間がかかります。
パフォーマンスへの影響: キーの数が多くなると、ページの読み込み速度が遅くなる可能性があります。【共通のキーを使用する場合のメリット・デメリット】
メリット:
管理の簡便さ: 1つのキーで全てのプラグインをカバーできるため、管理が容易です。
パフォーマンスの向上: キーの数が少ないため、ページの読み込み速度が速くなります。デメリット:
セキュリティリスクの増大: 特定のプラグインが攻撃された場合、他のプラグインにも影響が及ぶ可能性があります。
柔軟性の低下: 全てのプラグインに同じスコアリングが適用されるため、きめ細かい制御が難しいです。【どちらを選ぶべきか】
一般的に、以下の場合はプラグイン毎にキーを分けることを検討する価値があります。
サイトの規模が大きく、複数のプラグインを使用している場合
各プラグインのセキュリティレベルに差がある場合
高度なセキュリティ対策が必要な場合一方、以下の場合は共通のキーを使用することを検討できます。
サイトの規模が小さく、プラグインの数が少ない場合
セキュリティよりもパフォーマンスを重視する場合
管理の負担を軽減したい場合【その他の注意点】
スコアリング: reCAPTCHA v3 は、0から1までの間のスコアを返します。このスコアに基づいて、ボットかどうかを判断します。プラグインごとに最適なスコアリングを設定することで、セキュリティとユーザビリティのバランスを取ることができます。
エラー処理: reCAPTCHA の設定ミスやネットワークエラーが発生した場合、適切なエラー処理を行う必要があります。
定期的な見直し: reCAPTCHA の設定は、定期的に見直すことが重要です。Googleは、reCAPTCHAのアルゴリズムを常に改善しているため、古い設定では効果が得られない可能性があります。【まとめ】
reCAPTCHA のキーをプラグイン毎に分けるか、共通のキーを使用するかは、サイトの状況や要件によって最適な選択が異なります。どちらを選ぶにしても、メリットとデメリットをしっかりと理解し、慎重に判断する必要があります。より詳しい情報を得るためには、以下の点を考慮して検討することをおすすめします。
サイトの性質: ウェブサイトの種類、規模、扱うデータの重要度など
セキュリティ要件: どの程度のセキュリティレベルが必要か
パフォーマンス: ページの読み込み速度など
管理のしやすさ: 管理者のスキルや時間など
もし、より具体的なアドバイスが必要であれば、サイトの状況について詳しく教えてください。参考情報:
reCAPTCHA v3 のサイトキーとシークレットキーの取得方法: https://csgaku.com/blog-tech/recaptchav3/
ウェブサイト用の reCAPTCHA キーを作成する: https://cloud.google.com/recaptcha-enterprise/docs/create-key-website?hl=ja
免責事項:上記の情報は、一般的な情報であり、個々の状況に合わせた最適なアドバイスではありません。 最終的な判断は、ご自身で行ってください。
その他としましては、Google reCAPTCHA v2 は、面倒ですが案外有効だったりするかもしれません。
ネット情報ですが、v3 のスコア（閾値）を若干厳しく設定しておいて、ボット判定されたときは、自動的にv2に移行するという仕組みを導入しているところもあるようです。続いて、メール認証についてです。
ご提供いただきました会員情報画像から、メールアドレスについて任意の１０件を調べてみましたら、９件が過去に流出したメールアドレスとして登録されていました。 （参考：https://haveibeenpwned.com/ Have I Been Pwned (HIBP) API: 世界最大規模のデータ漏洩情報データベースの一つです。）
なので、こちらは、適当な実在しないメールアドレスではなく、実在するメールアドレスかと思われます。
何かチート的な方法ですり抜けたのかと思っていましたが、自動化した上で正攻法でメール認証を突破したのかと想像します。
当初は、不正な会員登録をしてきたメールアドレスをブラックリストとして登録できるようにすればいいのかと単純に考えていたのですが、毎回違うメールアドレスですし、そもそも、Welcart では既に登録された会員のメールアドレスは、重複して利用できない仕様となっており、これではブラックリスト化する意味もないことに気づかされました。
となると、Have I Been Pwned (HIBP) API やDehashed API、CyberChef といった外部APIサービスと連携できるようにしない限り、メール認証は突破され続けるのではないかと思います。これは、メール認証の性質として宿命みたいなものですね。一筋縄ではいかないかもしれません。長文大変失礼しました。よろしければ皆様のご意見をお待ちしております。
ikeda 様
いつもお世話になっております。
Welcart での対策をご検討いただけるとのこと、ありがとうございます。拡張プラグインについての、下記のご回答につき、他の拡張プラグインについても確認させてください。
WCEX Favorites は PHP8.1 に対応しております。
対応バージョンの更新が遅くなり大変申し訳ありません。私も、abisissy 様同様、拡張プラグインのPHP8.1対応待ちになっています。
拡張プラグインの中には、他にも PHP8.0 となったままの表記が複数あるのですが、それらも PHP8.1対応済みとなっていたりするのでしょうか？確か、Welcart Shop > ホーム 内の右側にある 「Welcart インフォメーション」において、Ver.2.10 の頃は、「Welcart 本体はPHP8.1に対応していますが、拡張プラグインの中には、まだ対応していないものがある」と表記されていたと記憶しています。Ver.2.11～は、そのような表記はなくなりました。このことを持って、全ての拡張プラグインは、PHP8.1 に対応済みと理解してよいものでしょうか？
Welcart システム要件については、「PHP 7.4から8.1」と明記されていますので、各拡張プラグインの【対応バージョン 】表記の更新が遅れているだけで、実際は対応済みとなっていますか？もし、WCEX Favorites だけ 対応バージョンの更新が遅くなっていたのでしたら申し訳ないことなのですが、Welcart Ver.2.11.3 現在で、 PHP8.1未対応の拡張プラグインがある場合は、まとめてご案内いただけますと幸いです。
abisissy 様
情報共有ありがとうございます。
PHP8.0 適正 スコア0.6 ですか。人力でやれそうな頻度でしょうか？
signifiant 様は、不正登録ですが、最後は数分に1度くらいの間隔となり、あまりにひどいのであちこち調べまして
と仰ってます。
これらは、本当に不具合なしで reCAPTCHA v3 突破してるんでしょうか。だとすれば、今後被害が増えるかもしれませんね。これは、Welcart様のほうで実装はされないでしょうか？
どうなんでしょうね。判断が分かれるところかも。突破された人が少数ならば、フックで今のところ対応できそうですし。
そもそもバリデーションで簡易なハニーポット作るよりも、reCAPTCHA v3 の方が格段に精度が高いイメージがあるので、実装したところで・・・というのもあります。不具合が確認されてるわけでもありませんし。
メール認証含め、まずは突破された方の情報が集まらないと何とも言えないかもです。signifiant 様
こんにちは。
勉強になります。usces_filter_member_check をこんな風に使ったことはありませんでした。
さながら、お手製のハニーポットですね。これで防げているのなら、これで様子見ということなりますでしょうか。確かに、電話番号はちゃんと数字のみを入れてきてるようですので、これではそのうち突破されるかもしれませんね。
私は、今のご時世FAXを非表示にしていますので、そういう場合ならFAXを正規表現で数字以外とはせずに、何か入力されたら、即ボット判定としても良さそうです。
外国からなら、フリガナに正規表現をつけても、それなりの効果が見込めそうです。
仕組み自体は、Jquery Validation でも可能ですね。あとは、よくあるケースとして
<input type="hidden" name="〇〇" >
で、最初から人間には見えない落とし穴を作っておくとかでしょうか。ハニーポットは、Welcart 本体でも搭載されると便利かもしれませんね。（このような古い技術では、今となっては、あまり意味がないのかもしれませんが・・・。）
ただ気になるのが、Google reCAPTCHA v3 がちゃんと仕事をしていないような気がしますので、一度確認された方が良いのではないかと思います。
Welcart Shop システム設定 > Google reCAPTCHA v3 において
｢Google reCAPTCHA v3 動作中response_OK｣
と表示されていますでしょうか？
また、スコア（閾値）は、いくつになっていますでしょうか？
デフォルトで 0.5 ですが、小さ過ぎるとボットを通過させやすくなります。
デフォルトより、1.0 に近づけるとより厳しい判定になりますが、厳しすぎると人間も通さなくなります。
一度、1.0 （人間でも 100% ボット判定される）にして、ご自身でフォームに入力してみて、ちゃんと機能しているかご確認ください。テスト後は、スコアを戻すのをお忘れなく。メール認証が突破されてるのも気になります。さっぱり分かりません。なんか悔しいです。これもちゃんと動いてますか？
不正登録自体は4月頃から来ていたようで、
この頃に、PHPのバージョンを、8.2以上にしてしまわれたのでしょうか？この頃は、メール認証は機能していて防げていたのに、
昨日からまた不正登録が頻繁に起こるようになりました。
ということは、9/6直前に、サーバー環境や新たなプラグインなど何か環境に影響を与える要因があって、ついにメール認証まで突破され、登録を許してしまったという流れでしょうか。
PHPのバージョンを正されたので、すでにそれだけで reCAPTCHA やメール認証が復活し、解決しているかもしれませんし、そうなれば、FAX の対策も不要かもしれません。また、経過を共有いただけるとありがたいです。
atskt 様
こんにちは。
まず、別のご質問の回答にもあるとおり、システム要件は、最低限守らなければなりません。何でも最新版が最善というわけではありませんのでご注意ください。
これを怠ると、いくら「バグ報告」だと言っても、不具合の検証すらしてもらえない（する価値がない）と思った方がいいと思います。中の方も限られた時間の中で回答されていますので、ご承知置きくださいますようお願いいたします。現在は、PHP8.1まで下げてから、症状をご報告ください。そして、投稿の前に、同様の質問がすでに存在していないか確認してください。詳しくは、このフォーラムをご利用上のお願いをご覧ください。
特に、「バグ報告」は、相応の再現性を検証してからでないと、「修正してください」と自信を持ってお願いするわけにもいかないのです。自分の使い方が間違っているかもしれない場合も念頭に置いて、はじめのうちは、「使い方全般」からご質問されることをお勧めします。
さて、本題ですが度々このフォーラムにも登場しております。検索していただくとすぐに見つかるはずです。
まずは、常時SSLの設定の確認から。
WPメニュー > 設定 > 一般設定
「WordPressアドレス (URL)」や「サイトアドレス (URL)」が https://～ になっているかご確認ください。
「s」 が抜けていませんか？おそらく、もう一方のご質問もこれが原因ではないかと思われます。
ak 様
こんにちは。
まずは、リリース情報をご覧ください。テーマのバージョンは、次から確認できます。
Welcart Shop > システム設定 > システム環境（タブ） > テーマ
または、
外観 > テーマ > (Welcart Basic) > テーマの詳細ZJ-kame 様
こんにちは。
PHP のバージョン：8.3.11
前回のご質問の回答は、ご覧になりましたか？
システム要件は最低限守らないと、不具合の検証が困難になると思います。
今一度、バージョンを下げてエラーが出るか、ご確認ください。生まれ年ワインショップ 様
暫く経ちまして、まだレスポンスがつかないようなのでコメントします。
不具合を、再現できませんでした。
関係のないプラグインの停止、子テーマ解除、カスタマイズなど解除して、もう一度ご自身で再現性を検証いただけませんか。コンソールもご確認ください。検証環境
WordPress 6.6.1
Welcart: 2.11.1
PHP:8.1.29
Welcart Basic:1.8.5
Win ChromeWelcart Shop 基本設定 > 郵便番号住所検索 利用する
nakamasdesign 様
確認ですが、アイコンとサムネを取り違えてませんか？
大多数の方は、アイコンを各商品のアイキャッチ画像には変更したいと思わないと思います。
各商品ということは、複数の画像に切り替えるということになりますので、そういう仕様ではありません。マニュアルにある、
タイトル左横のアイコンの表示
のタイトルとは、「Welcart お勧め商品」を指しています。商品名ではありません。
タイトル「Welcart お勧め商品」の左にある小さな画像がアイコンです。これは、マニュアルにあるとおり別の1枚の画像に変更することは可能です。FTPソフトやサーバーのファイルマネージャなどを用いて、その場所にそのファイル名でファイルを置くだけです。ここからは、アイコンではなく、サムネイルをアイキャッチ画像にしたいという意味だと仮定して書きます。
「Welcart お勧め商品」ウィジェットは、商品名と商品コードとメイン画像（Welcart Shop 商品情報編集の商品画像の1枚目）が使われますので、カスタマイズなしでは、これをアイキャッチ画像に変更することはできません。どうしても、メイン画像ではなくアイキャッチ画像にしたいということであれば、「デザインされた記事一覧（tcdバージョン）」ウィジェットを利用しましょう。これならノーコードで、FTPソフトも不要です。
タイトル：（例）おすすめ商品
投稿タイプ：商品
記事のタイプ：カテゴリー
カテゴリー：おすすめ
記事の表示順：(例)ランダム（「Welcart お勧め商品」ウィジェットは、ランダムです。）
☑価格を表示する：（お好みで）但し、「Welcart お勧め商品」ウィジェットは、「商品名＋商品コード」であるのに対し、「デザインされた記事一覧（tcdバージョン）」ウィジェットは、「商品詳細ページタイトル」になります。
もし、アイコンで間違いないということであれば、どこで悩んでおられるか、もう少し具体的にお書きください。
CBH 様
フォーラム上だけ文字化けしてしまったんですね。
この部分的な、usces_filter_shipping_rule で試してみましたが、やはり何度やってもエラーは再現しませんでした。
色々、考えてみました。。。
こちらでも発生する条件が分からず、漠然と
サイトが重たいように感じる時…ぐらいしか情報がなく申し訳ありません。
当社でも1回もみたことがない人もいますし、
10回に1回～5回に1回～3回に1回ぐらいの人もいるという感じです。この挙動は、キャッシュのあるなしの違いでしょうか？
毎回同じ商品でのテストでしょうか？ エラーがでるのは、array key 11 だけですか？
商品登録後に、usces_filter_shipping_rule を遡及して変更されてませんでしょうか？Chrome で「キャッシュの消去とハード再読み込み」は試されましたでしょうか？
関係のないプラグインは、すべて停止しておられますか？
特にキャッシュ系やセキュリティー系のプラグインは、無効化されてますでしょうか？
サーバー側のキャッシュ設定はどうなっていますか？どれかが、ヒントになればいいですね。
CBH 様
こんにちは。
> ◆2
同じ場所の一連のカスタマイズをして、usces_the_shipment_aim も使っていますが、100回やってもエラーは再現できません。もちろん、コードの上書きもしていません。なので、おそらくタイミングとかそういうものでもないと思います。
関係するコードを全てみればはっきりするのですが、全容がわからないので推測になります｡
一連のカスタマイズ後、商品詳細ページでデフォルトにはない、array key 11 で商品登録した後、usces_filter_shipping_rule で $shipping_rule の array key 11 を消してみて、無理矢理同じエラーを出してみました。
なので、おそらくエラーが存在するのは、 usces_filter_shipping_rule の $shipping_rule です。
ひとつ試してもらいたいことがあります。
シングルクォーテーションに見える‘や’の部分をキーボードを英数入力状態にして入力し直してみてください。
if($no>’9′){ $rules[10] =’取寄品：発送目安3～10日（土日祝除く）’; $rules[11] = ‘在庫品：(土日祝除く12時まで)当日発送予定’; ’9′ ’取 －－－ ）’ ‘在 －－－ 定’違いがわかりますか？（このフォーラムでの見え方も違うので、ご利用のエディタでどう見えているか不安ですが・・・）
Unicode U+0027 U+2018 U+2019 の違いです。（さらにわかりませんね。）
おそらくサイゼリヤの間違い探し級に、見つけるのが難しいです。
ちなみに私は肉眼で見つけられなかったので、ラッコツールズのPHP構文チェッカーに流し込みました。
いちいちエディターを立ち上げるのが面倒なときに、ラッコツールは大変重宝してます。今回も一発でした。また、このフォーラムでコードを書くときは、次回から＜code＞を使ってもらえると助かります。
よくある、エディタを経由してコピペを繰り返す間に文字化けしたのかもしれませんね。array key 11 と出ているということは、 key 10 より上が怪しいです。
そこから、シングルクォーテーションが正しく閉じられず、構文エラーが出ているのではないでしょうか。当たってれば、良いのですが。
> ◆3
私も最初は、同じ悩みを抱えていました。
カスタマイズは全てフック（無ければ無理を言ってフックを作ってもらっています。）で対応しているので、基本的にいつ自動アップデートがされても困ることはないのですが、過去にWelcart 本体の緊急ロールバックが必要になったことがあったため、大きな声では言えませんが、（キーマスターの方へ、フォーラムの運営上問題があるかもしれませんので、この部分は削除していただいた方が良いかもしれません。）私は、数時間だけ更新を遅らせて、必ず管理者の在席中に更新し、サイトに問題がないか確認するようにしています。
バグトラッカーを毎日チェックしていますので、そろそろ更新かな？というタイミングが予想できています。もちろん完全ではありませんので、リスクとトレードオフですが、リスクは最小限にしたいですから毎日チェックの努力は惜しみません。
全て自己責任です。おすすめはしません。生まれ年ワインショップ 様
こんにちは。
Google reCAPTCHA v3 自体がブラックボックスになっていますので原因の確証はないのですが、まだレスが付かないようですので、私の推測でよろしければ、参考程度にお読みください。先に結論から申し上げます。生まれ年ワインショップ 様のサイトを拝見いたしましたが、子テーマに原因があるのではないかと思っています。
まず、公式テーマをお使いの方は、一歩先のところにおられます。すなわち、すでにWelcart 様のほうで各テーマでの対応が済んでいますが、生まれ年ワインショップ 様のサイトではメインテナンスがなされておらず、古いままで運用されているということになります。おそらく、子テーマをお作りになったのがかなり前で、その後テンプレートが修正されているにもかかわらず、子テーマ化された古いファイルを読み込んでいるために反映されていないことが原因ではないかと思う次第です。
このトピックのタイトル
フォーム自動入力でreCAPTCHAに弾かれる
ということであれば、フォームの自動入力に関係のある、パスワード入力欄の “autocomplete 属性” について、最新の Welcart Basic と比較してみてください。Welcart 様では、autocomplete=”new-password” を推奨されている箇所がありますが、生まれ年ワインショップ 様のサイトでは、autocomplete 属性自体がありません。おそらくかなり前のものではないかと思います。
このフォーラムとバグトラッカーで「autocomplete」で検索すれば、詳しいトピックが出てきますので、よろしければご覧ください。私は、普段はTCDのテーマを使っているのですが、メインテナンスが十分になされず、サポート体制に非常に不満を持っていまして、できるところは自分でやるようになりました。この件に関してサポートに連絡してもずっと放置されたままです。
Welcart Basic のアップデートは本体と同じように重要なものとなっておりますので、私は、Welcart Basic に変更があったときには、バージョンごとに保存して、コンペアツールでフォルダごと比較して検証するようにしています。Welcart 様は大まかな変更点は公表されていますが、変更されたファイル名の情報がありませんので、自分で調べる必要があります。あとは、バグトラッカーの情報を手がかりに修正すべきところを調べ上げます。
一手間掛かりますが、子テーマ化されている以上は、必須かと思っております。長々と書きましたが、的を外しているかもしれず、はじめに申したとおり確証はありませんので、その際はどうかご容赦ください。私も長い間、Google reCAPTCHA v3 の誤判定には､ほとほと手を焼いてきたのですが、他にも思い当たることはあり、今なお研究中です。私の肌感覚なのですが、Google reCAPTCHA v3 は、同一 IP アドレスからのチャレンジを記録しており、子テーマを修正したとしても、一旦スコアの低下した IP アドレスの浄化（？）には数日かかる気がしています。ですので、反映にはしばらく様子を見る期間が必要ですので一喜一憂しながら待つ必要があると思います。また、ウイルス対策ソフトなどでVPNを使用している場合や、プロキシサーバー経由の場合も、かなりの確度でスコアが低下することがあるようですので、お心当たりがないかご注意ください。
それから、次もお役に立つかもしれません。ご参考までに。
reCAPTCHA v3 誤判定時のメッセージの書き換えについて
PAGE TOP