.htaccess が利用可能なのに.php（Stub）方式と判定される

  • Resolved miwarock777

    (@miwarock777)


    1 month, 3 weeks ago

    前スレッドでは判定ロジックをご説明いただきありがとうございました。

    その後、Password Protectedプラグインを使用していたために「テスト用 URL へ HTTP アクセスできないんだな」と思いましたので、原因切り分けも兼ねて試しておりますが、原因が特定できなかったため新たにスレッドを立てさせていただきました。

    改めてになりますが、今一度状況を書かせていただきます。

    【環境】

    本番環境・テスト環境ともにXserver（共用サーバー）を利用しています。

    以下は本番・テストともに同一です。

    ・WordPress 7.0
    ・SiteGuard WP Plugin 1.8.5（管理画面から手動アップデート）
    ・ディレクトリ構成
    ・WordPressアドレス／サイトアドレス
    ・.htaccess の内容
    ・WordPressはサブディレクトリへインストール
    ・WordPressのパーマリンクは正常に動作
    ・.htaccess は正常に利用できています。

    相違点は、テスト環境のみ Password Protected プラグインを利用していることです。

    【現象】

    「ログインページ変更」を有効にすると、本番環境では .htaccess 方式になりましたが、テスト環境では「このサーバーは .htaccess をサポートしていないため、ログイン URL は .php で終わります。」と表示され、.php（Stub）方式 になりました。

    テスト環境では、Password Protected を使っていることで、自己テストのアクセスが弾かれるから.php（Stub）方式 になるのだろうと仮説をたてました。

    【テスト環境で実施した確認】

    • ドキュメントルートおよびWordPressディレクトリの .htaccess を確認（WordPressディレクトリの.htaccess には、）
    • Rewriteは正常に動作
    • Password Protected プラグインを停止・削除
    • SiteGuard を停止・削除後、新規インストール
    • Password Protected を使っていない状態で、「ログインページ変更」をON・OFFを何度か

    以上を実施しましたが、
    やはり .php（Stub）方式 になってしまい .htaccess 方式 になりません。

    【おたずねしたいこと】

    • WordPress ルートに一時フォルダを作成し、その中に .htaccess（書き換えルール）とテスト用ファイルを置く
    • サーバー自身がそのテスト用 URL へ HTTP アクセスし、書き換えが効いて正しい応答が返るかを確認する

    ↑↑これらの自己テストがどの段階で失敗したかや、自己テストでアクセスしているURLや期待するレスポンスを確認する方法はありますでしょうか。
    現状では、なぜ .php（Stub）方式になったのかを管理者側で判断することができません。

    こちらとしては、.php（Stub）方式になること自体を問題視しているわけではありません。
    自己テストの結果として .php（Stub）方式 へ切り替わるのであれば、その仕様にも納得できます。
    ただ、管理者としては、なぜそうなったのかを理解できる状態で運用したいと考えています。
    アップデートや再設定時に意図せずログインURLの形式が変更される可能性があるのであれば、その理由を把握できるようにしたい、という思いです。

    お手数おかけしますが、よろしくお願いいたします。

Viewing 10 replies - 1 through 10 (of 10 total)
  • knaooka

    (@knaooka)

    1 month, 3 weeks ago

    miwarock777 さん

    現状では、診断結果を確認する方法がありません。

    検討いたしますので、少しお時間ください。

    よろしくお願いします。

    knaooka

    (@knaooka)

    1 month, 3 weeks ago

    miwarock777 さん

    診断情報を表示するバージョン（1.8.6-beta1）をリリースしました。ベータなので自動更新されません。以下のページの最下部より、1.8.6-beta1 をダウンロードしてください。

    https://wordpress.org/plugins/siteguard/advanced/

    「ログインページ変更」を有効にすると、本プラグインは「この環境で .htaccess が実際に機能するか」を自動テストします。テストに失敗して .php（Stub）方式へ切り替わった場合、1.8.6-beta1 では設定画面にその理由を表示します（同じ内容はPHPエラーログにも記録されます）。.htaccess 方式で成功した場合は理由は表示されません。

    場面ごとの表示は次のとおりです。

    • サーバーが Nginx → the server is Nginx, which does not use .htaccess.
    • Apache/LiteSpeed 以外のサーバー → the server is not Apache/LiteSpeed, so .htaccess is not used.
    • .htaccess に書き込めない → the .htaccess file (or the WordPress directory) is not writable.
    • 一時フォルダを作成できない → a temporary test directory could not be created in the WordPress directory (check write permission).
    • 一時ファイルを書き込めない → the temporary test files could not be written.
    • .htaccess が無視されている（AllowOverride None / mod_rewrite 無効）→ the .htaccess file is present but the server is ignoring it (for example AllowOverride is set to None, or mod_rewrite is not enabled for this directory), so the rewrite ... had no effect.
    • 自己テストの通信が失敗（ループバック不可・タイムアウト等）→ the self-test request to ... failed (...). The server may be unable to reach its own URL (loopback).
    • アクセス制限で弾かれた（HTTP 401/403）→ the self-test request to ... returned HTTP 401/403 instead of 200. It may be blocked by an access restriction such as Basic authentication or an IP restriction.
    • テスト URL が見つからない（HTTP 404）→ ... returned HTTP 404 instead of 200. The test URL was not found, for example because WordPress is installed in a subdirectory ... or the request is routed elsewhere.
    • リダイレクトされた（HTTP 3xx）→ ... returned HTTP 3xx instead of 200. The request was redirected (for example HTTP to HTTPS, or a canonical redirect).
    • 応答が想定外（HTTP 200 だが内容不一致）→ the self-test request to ... did not return the expected result; the .htaccess rewrite did not take effect ...

    よろしくお願いいたします。

    • This reply was modified 1 month, 3 weeks ago by knaooka.
    • This reply was modified 1 month, 3 weeks ago by knaooka.
    Thread Starter miwarock777

    (@miwarock777)

    1 month, 3 weeks ago

    knaooka 様

    早速ご対応いただきありがとうございます。
    インストールしていた1.8.5を停止→削除し、1.8.6-beta1 を利用させていただきました。
    （理由が表示されるのは大変分かりやすいです）

    下記のような表示がでました。

    Reason: the self-test request to https://xxxxx.com/siteguard-test-6a41f014c6e87/test.html returned HTTP 404 instead of 200. The test URL was not found, for example because WordPress is installed in a subdirectory so the self-test URL does not map to it, or the request is routed elsewhere.

    「応答が想定外（HTTP 200 だが内容不一致）」ということと理解しています。

    当環境は、

    • WordPressアドレス：https://XXXXXX.com/wp
    • サイトアドレス：https://XXXXXX.com

    という構成で、WordPress本体はサブディレクトリにインストールしています。
    この構成は、本番・テストともに同じです。

    取り急ぎ、診断結果をご報告いたします。
    必要な確認事項等がございましたら、お知らせください。

    knaooka

    (@knaooka)

    1 month, 3 weeks ago

    miwarock777 さん

    ご確認いただき、ありがとうございます。

    原因がわかりました。

    サブディレクトリにインストールし、サイトアドレスがサブディレクトリを含まない場合、
    /subdir/siteguard-test-…/ でテストを実施する必要があるのに、
    /siteguard-test-…/ で実施していました。
    ですので、結果が 404 Not Found になっていました。

    修正版 1.8.6-beta2 をリリースいたしました。
    お手数ですが、ご確認いただけますと幸いです。

    よろしくお願いいたします。

    Thread Starter miwarock777

    (@miwarock777)

    1 month, 3 weeks ago

    knaooka 様

    迅速にご対応いただきありがとうございます。

    早速1.8.6-beta2 を試してみました。
    今回は下記の結果となりました。

    ログインURL: https://XXXXXX.com/wp/login_XXXXX.php
    このサーバーは .htaccess をサポートしていないため、ログイン URL は .php で終わります。
    Reason: the self-test request to
    https://XXXXXX.com/wp/siteguard-test-6a42113866a15/test.html
    returned HTTP 429 instead of 200.

    前回の beta1 では自己テストURLにWPインストールディレクトリが含まれておらず HTTP 404 となっていましたが、beta2 では自己テストURLがWPインストールディレクトリ配下となり、404 は解消されていました。

    なお、テスト環境では Xserver の WAF は全項目 OFF にしており、サーバー側のWAFは利用しておりません。外部サービスや各種ツールとの連携を行うことがあるため、WAFの誤検知を避ける目的で意図的にOFFにしています。
    逆に、本番環境では WAF をすべて ON にしていますが、こちらは .htaccess 方式で正常に動作しています。

    もし追加で確認した方がよい項目や、取得した方がよい情報がありましたら、お知らせいただけますと幸いです。
    今回追加していただいた診断機能のおかげで、原因の切り分けがかなり進みました。
    迅速なご対応、本当にありがとうございます。
    引き続きよろしくお願いいたします。

    knaooka

    (@knaooka)

    1 month, 3 weeks ago

    miwarock777 さん

    ご確認ありがとうございます。

    404 が解消し、自己テスト URL が WP 配下を正しく指すようになったことが確認できました。

    今回の HTTP 429（Too Many Requests）はレート制限で、自己テストが叩くファイルは WordPress を読み込まない単独ファイルのため、プラグインが出しているものではなく、サーバー側のアクセス制限／集中対策によるものと考えられます（WAF とは別系統です）。

    お手数ですが、時間を置いてから、「ログインページ変更」をOFF→ONして、判定が変わるか（.htaccess 方式になるか）をお試しいただけますでしょうか。

    429 の解消はサーバー側のコントロールであるため、同様の結果である場合は、数時間、あるいは、数日待つ必要があるかも知れません。

    よろしくお願いいたします。

    knaooka

    (@knaooka)

    1 month, 3 weeks ago

    miwarock777 さん

    miwarock777 さんの環境での解決が確認できていませんが、今までの改善が多くのユーザーに有益であると判断し、1.8.6 を先ほどリリースしました。

    今回のご連絡が大きな改善につながりました。ありがとうございます。

    引き続き、よろしくお願いいたします。

    Thread Starter miwarock777

    (@miwarock777)

    1 month, 3 weeks ago

    knaooka 様

    ご確認ありがとうございます。
    また、迅速にご対応いただきありがとうございます。

    404 の原因は beta2 で解消され、現在は HTTP 429 が返っていること、
    また SiteGuard ではなくサーバー側のアクセス制限／集中対策（WAFとは別系統）による可能性が高いとのこと、理解いたしました。

    時間を置いてから、「ログインページ変更」をOFF→ONし、判定が変わるかどうか試してみます。
    結果が分かりましたら、改めてご報告させていただきますので、
    お手数ですがご確認いただけると幸いです。

    引き続きよろしくお願いいたします。

    Thread Starter miwarock777

    (@miwarock777)

    1 month, 2 weeks ago

    knaooka 様

    ご報告です。

    数日経過してから、プラグイン停止・削除後に 1.8.6 を改めてインストールし、「ログインページ変更」を実施したところ、当方のテスト環境でも .htaccess 方式となることを確認できました。

    この度は迅速かつ丁寧にご対応いただき、誠にありがとうございました。
    本件については解決済みとさせていただきます。

    今後も引き続き利用させていただきます。
    どうぞよろしくお願いいたします。

    knaooka

    (@knaooka)

    1 month, 2 weeks ago

    miwarock777 さん

    ご連絡ありがとうございます。良かったです。

    あらためまして、一連のご報告、ご検証いただき、ありがとうございました。

Viewing 10 replies - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.