ローカルカスタムドメイン名でリモートサーバにアクセスし、websocketとcookieをサポート
3263 ワード
シーン
会社では多くのテストマシンやOAサービス、Confluence、Jenkins、各種ミドルウェアのバックグラウンドなどがあり、HTTPアクセスを使用しています.また、イントラネットマシンにドメイン名がないため、IPを入力したり、異なるポートを入力したりするのは面倒です.
ソリューション
ローカルNginxを使用し、
ターゲット Cookieセッション転送 をサポート Websocketセッション をサポートは301などのリダイレクトをサポートし、redirect 以上の3点を備えると,ほぼ100%をカバーするウェブ機能が開発されたといえる.
アクションプラン
以上の構成は検証されました.
説明すべき事項
A.websocketと普通のhttpエージェントの違いは、前者にはこの3つが必要です.
Websocketは長時間保持されている接続なので、セッション時間を延長する必要があります.そうしないと、Nginxによって事前に切断されます.
B.Cookieはドメイン名に基づいているので、ターゲットマシンが発表したCookieは、ローカルのカスタムドメイン名に変更する必要があります.
この例では、ターゲットマシンアドレスは10.11.11.11であり、ローカルブラウザに入力されたドメイン名はsome.company-inc.comである.これにより,ブラウザにアクセスするため,サービス側がローカルブラウザに書き込むとCookieが正しくブラウザに受け入れられる.一方,ブラウザが要求を開始する際に付随するCookieは,Nginxエージェントにより実際のターゲットマシンのCookieに変換され,Domainは10.11.11.11に復元される.
C.サーバが301のようなリダイレクト要求を発行した場合、Locationフィールドは処理されなければならない.そうしないと、ブラウザは誤ったアドレスに転送される.
上記の構成を追加しない場合、Redirectリクエストを受信したとき、私が間違っていなければ、ブラウザは
D.次の構成は、JSリクエストで発生したCORS関連のエラーが発生した場合、発生する可能性のあるドメイン間問題を解決するためのものです.
会社では多くのテストマシンやOAサービス、Confluence、Jenkins、各種ミドルウェアのバックグラウンドなどがあり、HTTPアクセスを使用しています.また、イントラネットマシンにドメイン名がないため、IPを入力したり、異なるポートを入力したりするのは面倒です.
ソリューション
ローカルNginxを使用し、
C:\Windows\System32\drivers\etc\hosts(/etc/hosts Linux/MacOS.)
を構成ターゲット
アクションプラン
server {
listen 80;
server_name some.company-inc.com;
#charset koi8-r;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
location ~ /microservices/api/ws {
proxy_http_version 1.1;
proxy_pass http://10.11.11.11:8084;
proxy_redirect default;
proxy_cookie_domain ~\.?10.11.11.11 some.company-inc.com;
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 600s;
proxy_connect_timeout 600s;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Origin "";
proxy_buffering on;
proxy_send_timeout 300s;
client_max_body_size 2048M;
}
location / {
proxy_pass http://10.11.11.11:8084;
proxy_redirect http://some.company-inc.com:8084/ /;
proxy_cookie_domain ~\.?10.11.11.11 some.company-inc.com;
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_connect_timeout 600s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
client_max_body_size 2048m;
}
}
以上の構成は検証されました.
説明すべき事項
A.websocketと普通のhttpエージェントの違いは、前者にはこの3つが必要です.
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
Websocketは長時間保持されている接続なので、セッション時間を延長する必要があります.そうしないと、Nginxによって事前に切断されます.
proxy_connect_timeout 600s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
B.Cookieはドメイン名に基づいているので、ターゲットマシンが発表したCookieは、ローカルのカスタムドメイン名に変更する必要があります.
proxy_cookie_domain ~\.?10.11.11.11 some.company-inc.com;
この例では、ターゲットマシンアドレスは10.11.11.11であり、ローカルブラウザに入力されたドメイン名はsome.company-inc.comである.これにより,ブラウザにアクセスするため,サービス側がローカルブラウザに書き込むとCookieが正しくブラウザに受け入れられる.一方,ブラウザが要求を開始する際に付随するCookieは,Nginxエージェントにより実際のターゲットマシンのCookieに変換され,Domainは10.11.11.11に復元される.
C.サーバが301のようなリダイレクト要求を発行した場合、Locationフィールドは処理されなければならない.そうしないと、ブラウザは誤ったアドレスに転送される.
proxy_redirect http://some.company-inc.com:8084/ /;
上記の構成を追加しない場合、Redirectリクエストを受信したとき、私が間違っていなければ、ブラウザは
http://some.company-inc.com/10.11.11.11:8084/xxxxxxx
のようなアドレスにアクセスします.D.次の構成は、JSリクエストで発生したCORS関連のエラーが発生した場合、発生する可能性のあるドメイン間問題を解決するためのものです.
proxy_set_header Origin "";