Discourse は Apache を使用していないため、.htaccess（Apache）で行うように、例えばステージング環境（Discourse Docker を使用した Digital Ocean ドロップレット）をパスワード保護するにはどうすればよいでしょうか？
Apache は存在しませんが、Discourse コンテナ内で NGINX が実行されています。このトピックが役立つかもしれません：
「いいね！」 3
完璧です、ありがとうございます @david 
「いいね！」 1
追加したのですが、今では https://cdn-uploads.example.com および https://cdn-origin.example.com のすべての画像で認証パスワードの入力が求められます。https://discourse.example.com のみを保護することは可能でしょうか？
そうしないと、現在このような表示になります：
それがどう実現するかは正確にはわかりませんが、アイデアをお持ちの方が参加してくれるかもしれません。nginx の設定をいくつか調整すれば可能はずです。
回避策として、またこれはステージングサーバーであることから、CDN を無効にすることはできませんか？アセットに同じドメインを使用すれば、認証ヘッダーが自動的に送信されるため、認証パスワードを再度入力する必要はありません。
「いいね！」 1
はい、その通りです。本番環境で S3 バケットをバックアップやアップロードに、CloudFront をアップロード用の CDN およびオリジンとして使用する場合、ステージング環境でも同様の構成が推奨されますか？
ステージング環境では、それらすべてを完全に用意する必要はないのでしょうか？
この nginx の変更は、S3 アップロードや S3 CDN には決して影響を与えるべきではありません。そこには NGINX は一切関与していません。ローカルアップロードを CDN とともに使用していると想定していましたか？
理想的な状況は、ステージングサイトを本番環境と同一に設定することです。
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
また、ステージング環境のメインドメインは現在 https://staging.example.com です。
それでも、提案されたコードを使用し https://staging.example.com にアクセスすると、cdn-origin からのすべてのリクエストに対して認証プロンプトが表示されます。
同じ問題に遭遇している方のための更新情報:
cdn-origin に対して CloudFront で Authorization ヘッダーのホワイトリスト登録を行いました。
cdn-uploads については、認証を求められていなかったようです。
現在、動作しています。
「いいね！」 2
ステージングサイトではログイン必須をオンにしました。アプリ.yml で環境変数を設定すれば、その設定を永続化できます。
Google や他の誰かがサイトを発見してしまうなら、それは十分ではありません。とにかく、今は動作しています。
「いいね！」 1
サイトは表示されますが、コンテンツは表示されませんよね？
私たちの場合、匿名ユーザーに対するサイトの反応も確認できる必要があります。つまり、basic_auth で動作するようになったので、問題ありません。
「いいね！」 2
ええと、あなたのその言葉で、私のやり方を考え直させられましたね！
@Terrapop さん、こんにちは
これはあなたへのアイデアで、私たちが行っている方法です。
ステージング環境を Apache2（または nginx）をリバースプロキシとして実行している場合、.htaccess で行うように、リバースプロキシでアクセスルールを設定できます。
Discourse をリバースプロキシの背後で実行することには無数の利点があり、アクセス制御の容易さはその一つのメリットに過ぎません。
参考になれば幸いです。
Nginxの完璧な手順ガイドはありますか？DigitalOceanのDropletとDockerを通じてホスティングしています。
こんにちは、@Terrapop さん
Meta には、リバースプロキシの背後で「2 コンテナ」構成で Discourse を設定する方法についての優れたチュートリアルが多数あります。
Meta で以下のように検索してみてください。
two container reverse proxy
これが役立つことを願っています。
なお、単なるステージング環境の場合、多くの人は「2 コンテナ」構成を設定せず、本番環境でのみこれを行います。しかし、本番環境と「完全に同じ」状態でステージングしたい場合は、「2 コンテナ」構成は非常に優れた選択肢です。ただし、リバースプロキシの背後で Web アプリを実行するために「2 コンテナ」構成は必須ではありません。私は開発環境と本番環境の両方で、ROR および Docker Web アプリをリバースプロキシの背後で定期的に運用しています。
「いいね！」 3
こんにちは。CloudFront で認証ヘッダーを正しくホワイトリストに登録する方法について教えていただけますか？上記の通り、app.yml に「auth_basic」を追加しました。デスクトップから閲覧する際はパスワード保護が機能していますが、モバイルから閲覧すると（ユーザー名とパスワードを入力後）、以下のエラーが表示されます：
私の「cdn-origin」には以下が設定されています：
「whitelist-authorization-headers」ポリシー：
CloudFront は比較的新しい分野であり、モバイル設定において非常に明らかな何かを見落としているのかもしれません。