基本認証モジュールを有効にして開発サイトを保護するにはどうすればよいですか？
開発段階では、開発サイトは不正な訪問者が閲覧できないように保護する必要があります。通常、Webサーバーで構成された基本認証を使用します。このようにして、不正な訪問者が取得する唯一の情報はドメイン名です。
Drupal 8は、基本認証またはOAuthをREST（Cookieメソッドなし）に使用します。
開発サイトを保護し、基本認証でRESTを使用する場合は、問題があります。通常、上記のように、基本認証を使用するようにWebサーバーを設定します。ただし、基本認証モジュールを有効にすると、Drupalは基本認証ヘッダーの処理も試みるため、Drupalは403アクセス拒否をトリガーします。
問題：
- ヘッダーはDrupalにも送信され、Drupalはそれを使用しようとします。これにより、Webサーバーの基本認証がDrupalユーザーと一致しないため、403が提供されます。
- 2つの基本認証ヘッダー（1つはWebサーバーまたは外部レイヤー用、もう1つはDrupal用、RESTサービスを使用する場合）を使用する場合は、RESTサービスを微調整します。これらの2つのヘッダーを送信するコンシューマー。また、Webサーバーまたは外部レイヤーは、Drupalが使用する正しいヘッダーとパスヘッダーを削除する必要があります。
明白な解決策
- （OAuthサービスには常にRESTを使用してください）OAuthはAuthorizationヘッダーも使用しているようで、解決策ではありません。
- 基本認証以外の方法で開発サイトを保護します。
これを達成する他の方法は？
[〜＃〜] note [〜＃〜]：クライアントは静的IPを持たず、VPNを使用して接続できません（これは主に、顧客が開発サイトを確認できる必要があるためです）。
時間が経ちましたが、今はより簡単な方法を見つけました。使用 シールドモジュール
PHP認証シールド。これは、Apache認証を使用してサイトの単純なシールドを作成します。ユーザーが単純なユーザー名/パスワードを知らない場合、サイトを非表示にします。これは、Drupalを「壁に囲まれた庭」として扱います。このモジュールは、HTTP認証で（開発）サイトを保護するのに役立ちます。
その構成により、特定のパスをホワイトリストに登録できます。 RESTパスは、独自の認証メカニズムをすでに持っているため、ホワイトリストに登録できます。Apacheまたは他のWebサーバーで動作します。
ホワイトリスト機能は、Drupal 8 のパッチとしてのみ使用できることに注意してください。
手順は次のとおりです。
- .htaccessを変更して
DirectoryIndex index.html index.phpを読み取る - Index.htmlファイルを作成して、必要なものをすべて表示します。
- Robots.txtを変更して、検索エンジンロボットによるサイトのインデックス登録を禁止します。
クライアントは http://www.example.com/index.php をいつでも確認でき、完了したら.htaccessとrobots.txtを元に戻すことができます。
私が目にする唯一の解決策は、Drupalより前にあるVarnishやNginxなどの外部レイヤーを使用することです。このレイヤーは、マジックキー（特定の値を持つURLパラメータ、Cookieまたはカスタムヘッダー）をチェックできます。マジックキーが存在する場合、外部レイヤーはマジックキーを削除し、リクエストをバックエンド（Drupal）に配信します。マジックキーが存在しない場合、この外部レイヤーは403を返します。
この外部層は、IP、範囲、または開発ライフを容易にするためのあらゆる方法をチェックできます。
図： 
こちらです：
- マジックキーがない限り、サイトは完全にプライベートです。サイト情報が漏洩することはありません。
- Authorizationヘッダーの競合はありません。
- クライアントにCookie、URLパラメータ、またはヘッダーを追加することで簡単にバイパスできます。テクニカルユーザーでない場合は、URLパラメータを使用する必要があります。この場合、このパラメーターが検出されたときに、外部レイヤーはマジックキーを含むCookieを追加することもできます。したがって、次のリクエストは、この追加されたCookieのおかげで通過します。
- Drupalに対して透過的：Drupalは決して知りません。
欠点：
- 外部レイヤーを設定する必要があります。
- リクエストには魔法の鍵を提供する必要があります。これは、技術的でないクライアントにとって厄介なことです。
この回答 いくつかの問題を解決できません。通常、会社のログやその他の情報があるメンテナンスモードのページが表示されるため、サイトに関する情報が漏洩します。また、サイトを閲覧するか、RESTサービスを管理ユーザーとして使用することしかできないため、他のユーザーとサイトをテスト/チェックすることはできません（たとえば、権限はすべてをパスします。ユーザーが他のユーザーにサイトを閲覧する許可を与えることでこれを軽減できますが、最終的にはサイトの実際の動作を変更します。サイトに対する保護は透過的である必要があります。
十分に公正な場合は、使用する必要があります
メンテナンス免除
Drupalでは、コードとデータベースのアップグレードを安全にデプロイするために、サイトをメンテナンスモードに設定できます。ただし、メンテナンスモード中のサイトへのアクセスは、デフォルトでは、通常は管理ユーザーにのみ与えられる権限によって制御されます。すべての匿名/認証済みユーザーに「メンテナンスモードでのサイトの使用」権限を付与せずに、通常の匿名または認証済みユーザーとしてサイトをテストすることはできないため、通常、サイトを「ライブ」モード。
これまで、それは！このD7 +モジュール（必要なフックはD6以下には存在しません）により、特定の人々がすべての訪問者にサイトを開かなくても、すべての役割の組み合わせでサイトで必要なテストを実行できます。
ここで、メンテナンスモードページにロゴを表示したくない場合は、
/modules/system/にあるmaintenance-page.html.twigをコピーして、/sites/all/themes/[your theme]/templatesフォルダーに貼り付けます。
次に、ファイルを編集し、{{ logo }}と必要なものをすべて削除します。おそらくすべて？
「基本認証以外の方法で開発サイトを保護したい場合」、 「 モジュールのアクセス許可をより細かくするにはどうすればいいですか？ 」に関する質問への私の回答を確認してください。これは（のみ） Rules モジュールを使用します。これには、含まれているルールの要約が含まれます。
- ルールイベント：Drupalは初期化中です。
- ルール条件：匿名ユーザーかどうかを確認し、アクセス権のない一部のURLにアクセスしようとしたかどうかを確認します。
- ルールアクション：ルール条件を満たすユーザーを「代わりに他のURL」にリダイレクトします（情報メッセージが表示されます）。
これらのルールの条件とアクションで使用されるURLを調整することにより、探しているものに近くなる可能性があります。
このルールはDrupal 7で完全に機能しますが、Drupal 8の設定ではまだテストしていません。ただし、最新の開発者で実験する価値はあるでしょう。ルールのバージョンDrupal 8（同様のルールを作成するため）。
注：「のようなものを探している場合、特定のURLパラメータvalue "（あなた自身の答えのように） Rules URL argument モジュールを検討することもできます。詳細については、「 ルールモジュールにクエリ文字列を含むURLへのリダイレクトを実行させる方法 」に対する私の回答を参照してください。
開発段階では、開発サイトは不正な訪問者が閲覧できないように保護する必要があります。
1つは、箱から出してすぐにサイトをメンテナンスモードにすることです（/admin/config/development/maintenance）。したがって、管理者のみはサイトを表示/閲覧できます。
ログインするには、手動で/user/loginにアクセスする必要があります