Alicia
投稿の際は下記の情報をお書き添えください。
-------------------------------------------
WordPress のバージョン：（例 6.0.2）
Welcart のバージョン：（例 2.8.1）
PHP のバージョン：（例 8.0）
Welcart専用の拡張プラグインとバージョン：（例 DL Seller 3.4.1、SKU Select 1.4.2）
ご利用の親テーマとバージョン :（例 Welcart Basic 1.7.1）
ご利用の子テーマとバージョン :（例 Welcart Beldad 1.4）
症状を確認したブラウザ：
サーバー【重要】：（会社名、サービス名）
--------------------------------------------
フォーラムへの返信
-
投稿
-
毎日ウェブ 様
新しいバージョンを確認いたしました。この度は、迅速にご対応頂きまして誠にありがとうございました。
また、新たな形での機能復活など、これからも益々のご発展を期待しております。ikeda 様
yasumax 様お世話になりました。トピックタイトルの最大長の修正も含め、ありがとうございました。
本件、解決済みとしてください。よろしくお願いいたします。毎日ウェブ 様
ご丁寧にご連絡ありがとうございます。
この度はお時間を取ってしまい誠に申し訳ありません。安全策ということで納得いたしました。
もし私の方で何か分かったことがあれば、またご報告させていただきます。それから、私は正真正銘のど素人ですので、フォーラムで間違ったことも臆することなく発信してしまっていると思います。お気づきの点がございましたら遠慮なくご指摘いただけますと幸いです。
今後ともよろしくお願いいたします。毎日ウェブ 様
こちらこそ、お手数をお掛けして申し訳ありません。
そうですか、再現しませんでしたか。力及ばすで申し訳ありません。
何か、まだ隠れた条件があるのだと思います。私の環境がマイノリティということも考えられますので、その場合、この機能を重宝されている方（私もその一人です）に大変心苦しいことにもなりかねないため、機能の削除はされなくても良いのではないでしょうか。発生条件を正しく解析できればいいのですが、なにぶん素人なので要領を得ません。もう少し粘ってみます。
少し手かがりが掴めました。
念のため、サーバー側の設定でブラウザキャッシュも確認しましたが、「オフ」になっておりました。
テスト環境はいつもできるだけデフォルトに近い環境で行っているのですが、条件が合致すると、不具合が再現してしまいます。素人ながら、甚だ僭越ではございますが、よろしければ少し教えて頂きたくお願いいたします。
FFW Ver.1.2.3 の該当のコードにおいて
576 /* 「戻る」でドキュメント有効切れを防ぐ */ if(!empty($preventExpiration) && $preventExpiration == 'yes'){ function friendly_functions_for_welcart_add_header_session() { 580 header("Cache-Control: private"); header("Pragma: no-cahce"); header("Expires: "); header("Last-Modified: "); } add_action('send_headers', 'friendly_functions_for_welcart_add_header_session'); }こちらの
580行目 cache-control: privateで、クライアント側でキャッシュ可能になっているのではないでしょうか？
機能上必要なのだと思いますが、Chrome の検証ツールのネットワークで確認しましたところ、この機能を「利用する」にしますと
https://〇〇〇.com/usces-member/?usces_page=member_edit
がディスクキャッシュから配信されているのを確認しました。ディスクキャッシュを使っているために、サーバーに取りに行かず、本人確認メールの送付がトリガーされなかったのかと推測しました。
このあたりの仕様と挙動が正しいものなのかも含めて私にはよくわからないのですが、想定された挙動でしょうか？
試しに、ネットワークにて ☑キャッシュを無効化 にしてやると、キャッシュされずにサーバーから読み込まれることで、本人確認メールが送られるようになります。ブラウザでスーパーリロードしても、その瞬間にメールが送信されてきます。
お客様に都度リロードを促すことも現実的ではないので、どうしたものかと思います。
あるいは、ディスクキャッシュされていても、本来はメールは送信されるものなのでしょうか？
申し訳ありませんが、上記の挙動確認のため、ディスクキャッシュされるか、その場合メールが送信されるか、ご確認頂けないでしょうか。お忙しいところ恐縮ですがよろしくお願いいたします。
以下、私の環境で発生した、メールが送信されない不具合の発生機序を示します
（キャッシュの取り扱いの検証のため、メール認証を経由する場合も、同一端末、同一ブラウザで操作します。）１．マイページから 会員情報編集へ>> をクリック
→ メールが送信されるのを確認する（この時点で不具合は発生していない）２．ＦＦＷにて、ユーザビリティ設定 > 「戻る」によるドキュメント有効切れ防止 → 利用する に変更する → 設定を保存
３．会員認証 （認証メールを送信しました） の画面でブラウザをスーパーリロード（キャッシュを作る） → 再び本人確認メールが送られる
４．会員をログアウトする
５．ログイン画面からログインする
６．マイページから 会員情報編集へ>> をクリック
このとき https://〇〇〇.com/usces-member/?usces_page=member_edit のレスポンスヘッダーが cache-control:private なのでディスクキャッシュから読み込まれる → メールは送信されない（不具合発生）ここで ４．５．６．を何度繰り返しても、本人確認メールが送られることはありません。（不具合の継続確認）
７．６でブラウザをリロードする
このとき https://〇〇〇.com/usces-member/?usces_page=member_edit が強制的にサーバーから読み込まれる → メールが送信される試しに、５８０行目をコメントアウトしますと、メールは送られます。
毎日ウェブ 様
ikeda 様
yasumax 様お手数をお掛けして申し訳ありません。
検証いただきありがとうございます。何か他に条件があるのかもしれません。
もう少し探ってみます。一旦、取り下げさせてください。
お騒がせしてすみません。進展があればご報告いたします。本件につきまして、
2024/9/20 【EGO.（Welcart版）】Ver1.12→1.13■特定の条件下で新規会員登録メール認証のURL遷移先が異なる不具合の修正
にて、不具合が解消されたことを確認し、無事、メガメニューＢが利用できるようになりました。
このトピックは解決済みとしてください。よろしくお願いいたします。
皆様
情報提供に感謝いたします。
どうやら、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) > テーマの詳細
PAGE TOP