サイトをパスワード保護する

Password protection puts a browser sign-in prompt in front of your whole site or a specific path, which is the simplest way to keep a pre-launch site, a staging copy, or an admin area private. This…

パスワード保護はブラウザのサインインプロンプトをサイト全体または特定のパスの前に配置し、プリローンチサイト、ステージングコピー、または管理エリアをプライベートに保つ最もシンプルな方法です。このガイドではセットアップ、ユーザー管理、動作確認、および削除方法をカバーしています。

KPanel におけるパスワード保護の場所

KPanel にサインインします。
左側のサイドバーで Websites をクリックし、サイトをクリックします。
サイトのタブストリップで Advanced を開き、次に Password protection を開きます。

直接アドレスは /websites/<site-id>/password-protect です。

KPanel でのサイトのパスワード保護

仕組み

保護はアプリケーションが実行される前に HTTP Basic Auth を使用してウェブサーバーによって適用されます。保護された URL への訪問者はブラウザ独自のサインインダイアログを取得し、認証されるまでコンテンツを見たり、アプリケーションコードに到達したりできません。

すべての前に配置されているため、レンダリングされたページだけでなく、同じパスの下にあるアセット、アップロード、API エンドポイントも保護します。また検索エンジンクローラーも完全にブロックします。これはプリローンチサイトで正確に望まれるものです。

保護対象の選択

Add protection をクリックすると、最初の質問はスコープであり、2 つの答えがあります。

Protect entire site。 ドメイン、ルート、管理画面、すべてを訪問するすべての人がサインインプロンプトを取得します。これはまだ起動していないサイト、ステージングコピー、または公開読取可能でないサイトの適切な選択です。

Protect a specific path。 1 つのサブパスをロックし、サイトの残りは公開のままにします。パスの下のすべてが含まれるため、/admin を保護すると /admin/users もカバーします。

サイト上で複数の保護を作成でき、それぞれが異なるパスをカバーし、異なるユーザーを持つことができます。

セットアップ

Add protection をクリックします。
Protect entire site または Protect a specific path を選択します。パスの場合、/admin のようにスラッシュで始まる形式で入力します。
Prompt label を設定します。これはブラウザのサインインダイアログに表示されるテキストで、最大 64 文字です。デフォルトは Restricted area です。サイト名などの認識可能なものを使うと、訪問者がプロンプトがフィッシング試行ではなく本物であることを認識するのに役立ちます。
ユーザー名と最低 8 文字のパスワードを持つ少なくとも 1 人のユーザーを追加します。
アクセスが必要な追加の人ごとに Add user をクリックします。
Apply protection をクリックします。

ルールが適用され、サイトに対して直接チェックされるため、その後に表示されるステータスは実際の動作を反映しています。

Basic Auth 認証情報はすべてのリクエストで送信されます。HTTPS では転送中に暗号化されます。これはステージングサイトまたは内部エリアのゲーティングには問題ありません。これは ID システムではありません。ユーザーごとの監査証跡、セッション、パスワードリセットフロー、失敗した試行後のロックアウトはありません。本当に機密性の高いものを保護するために使用しないでください。また、チームが他の場所で使用するパスワードを再利用しないでください。

ユーザー管理

編集ボタンで既存の保護を開き、ユーザーリストを変更します。

ユーザーの追加: Add user をクリックし、ユーザー名とパスワードを入力します。
パスワードの変更: そのユーザーのパスワードフィールドに新しいパスワードを入力します。
パスワードを保持: フィールドを空白のままにします。既存ユーザーはパスワードが変更されていないことを示すプレースホルダーを表示します。
ユーザーの削除: そのユーザーの行の削除ボタンをクリックします。

パスワードは表示されることはありません。誰かが自分のものを忘れた場合、新しいものを設定して伝えてください。

既存の保護のスコープは変更できません。保護をあるパスから別のパスに移動するには、削除して新しいものを作成します。

動作確認

各保護はステータスバッジを表示します。

バッジ	意味
Not yet verified	チェックはまだ実行されていません。しばらく後にリフレッシュしてください
Protection verified live (401)	外部から URL をリクエストし、本物のサインインチャレンジを取得しました
Applied but not challenging, with a status	ルールが記述されていますが、サイトが別の応答をしました

中央のバッジが必要なものです。外部リクエストが本当にチャレンジされたことを意味し、設定ファイルが書き込まれたのではありません。

各行に Test ボタンもあり、保護された URL を新しいタブで開いてプロンプトを自分で確認できます。プライベートウィンドウでそれを実行してください。サインインしたら、ブラウザは認証情報を送信し続け、サイトはあなたに対して開いているように見えます。

保存後に別の設定がサーバー上で同じドメインをクレームしていることを示す警告が表示される場合、その競合が解決されるまで保護は適用されません。メッセージは他の設定を名前で示します。不確かな場合はサポートにお問い合わせください。

保護の削除

保護の削除ボタンをクリックして確認します。確認は結果について明示的です: ログインプロンプトが削除され、パスまたはサイト全体が誰でもアクセス可能になります。

削除後、パネルはサイトを再度チェックします。サイトがまだ開いていることを確認できない場合、成功を主張するのではなく、約 30 秒待ってリフレッシュするように指示します。

全サイト保護を削除するとサイトは検索エンジンを含む全インターネットに即座に公開されます。ローンチ日にそれを実行する前に、コンテンツが本当に準備できていることを確認してください: 正しいページが公開され、テストコンテンツが削除され、プレースホルダー価格が修正されています。

一般的な使用例

プリローンチ。 ビルド中にサイト全体を保護します。ライブになったら削除します。これは「近日公開」プラグインよりも信頼性が高いです。管理画面、アップロード、ステージングデータも非表示にするからです。

ステージング環境。 公開読取可能なステージングコピーは重複コンテンツの問題であり、データリークのリスクです。保護して保護したままにしてください。Staging Environments を参照してください。

WordPress 以外のサイト上の管理エリア。 静的サイトまたはカスタムアプリケーション (/admin パスを持つ) に対して、これはアプリケーションが既に行っていることの前にセカンドロックを配置します。

クライアントレビューサイト。 クライアントに 1 つのユーザー名とパスワードを与え、プロンプトラベルは何にサインインしているかを伝えます。

トラブルシューティング

プロンプトが表示されますが、パスワードが拒否されます。 ユーザー名に先頭または末尾のスペースがないことを確認し、編集ダイアログからパスワードを再設定してください。パスワードは最低 8 文字である必要があります。

サイトは開いているように見えていますが、他の人には保護されているように見えます。 ブラウザが認証情報をキャッシュしています。プライベートウィンドウでテストしてください。

稼働率監視ではサイトがダウンしていると報告されるようになりました。 全サイト保護で予想されます: チェッカーが 401 を取得します。Site Uptime Monitoring を参照してください。インシデント理由に 401 が表示されます。

検索エンジンのページがドロップされました。 保護が有効な場合も予想されます。削除してサイトがクローラブルになると復帰します。

バッジは適用されているが課題を提示していないと言われています。 ルールの前に何かが応答しました。表示されているステータスコードを確認し、そのパスのリダイレクトがリクエストを最初にキャッチしているかどうかを確認し、Site Redirects を参照してください。

保護を削除できません。 削除にはサイト書き込み権限が必要です。読み取り専用ロールではボタンは無効になります。