☰

CORS関連ヘッダをapache2（debian）のリバースプロキシに渡す

tag-icon • tag-icon apache-httpd
CORS関連ヘッダをapache2（debian）のリバースプロキシに渡す

数日間、この問題を解決できなかったので質問させてきました。私が達成したいのは、apache2を使用してnodejs / Expressバックエンドにリバースプロキシを設定することです。 http および websocket 接続プロキシは正常に機能しますが、CORS の有効化は機能しません。アプリケーションは、外部ホストのクライアントがインポートするウィジェットを提供するために必要です。ここでの主なメッセージは、corsがexpressjsのcors（）ミドルウェアによって処理され、関連するすべてのヘッダー/要求がapache2を介して対応するバックエンドサーバーにプロキシ処理されなければならないことです。以下は、さまざまなディレクティブを理解する方法のいくつかの説明を含む現在の構成です。

<VirtualHost my.domain.name:80>
 # redirecting all requests to https (works fine)
</VirtualHost>

<VirtualHost my.domain.name>
 
 LogLevel debug # does not log any information regarding the headers

 ServerName my.domain.name
 ServerAdmin [email protected]

 ## SSL directives removed for clarity
 ## logfile directives removed for clarity

 # forward requests to proxy =>
 ProxyPreserveHost On # Not sure if this is required as I forward the Origin header

 <Location "/"> # proxy all requests
  ProxyPass "http://localhost:3333/" # location of the backend server
  ProxyPassReverse "http://localhost:3333/" # required
 </Location>

 #ProxyRequest Off # Throws an error (unknown directive), but disabled by default, so not required
 
 # forward socket.io requests removed for calrity

 ## Required headers for CORS:
 # crucial CORS-related header that indicates the origin of the requesting domain
 RequestHeader set Origin "%{ORIGIN}e"

 # used in CORS preflight requests to indicate the HTTP method
 RequestHeader set Access-Control-Request-Method "%{REQUEST_METHOD}e"

 # used in CORS preflight requests to indicate the requested headers
 RequestHeader set Access-Control-Request-Headers "%{HTTP_ACCESS_CONTROL_REQUEST_HEADERS}e"

</VirtualHost>

ローカルでは、nginxを使用してリバースプロキシの背後にあるウィジェットをテストしましたが、うまく動作します（他のポートのCORSを含む）。

server {
   # omitted meta and SSL specific directives for clarity
 
   location / {
    proxy_pass      http://127.0.0.1:3333;

    # enable websocket passthrough
    proxy_http_version  1.1;
    proxy_set_header    Upgrade $http_upgrade;
    proxy_set_header    Connection "upgrade";

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
   }

}

私はnginxが原点またはOPTIONSプリフライト要求に関連するものを設定しないことを発見しました。また、私が知っている限り、HostとX-Real-IPはcorsと直接関係がありません。これがなぜ機能するのか知りたいです。 Expressのcorsミドルウェアがプロキシ要求を検出したときに情報の欠落について不平を言わないようにするために、以前はapache2構成にX-Forwarded- *ヘッダーを含めました（無用）。

mod_proxyとmod_headersのapache2ドキュメントを読んでこれを行う方法についての情報をWebで検索しながら、私の脳が溶けていて、ここで私が欠けている/間違っている部分についての実現を本当に期待しています。よろしくお願いします！

編集する 明確に言えば、Corsは（リバースプロキシを使用せずに）ウィジェットを直接要求したときに機能するため、正しく設定されているようです。

また、間違ったスタック交換に投稿して申し訳ありません（おそらく...）。私はserverfaultが正しいページかもしれないことに気づきました。しかし、私は主に前後に渡されるヘッダの適切なデバッグログを取得するなど、デバッグする方法に興味があります。問題のネットワーク関連の背景についてお手伝いできない場合は、serverfaultにお問い合わせください。 :)

関連情報