將身份驗證標頭從 apache 轉發到 nginx 的奇怪問題 - 在繼續請求中找不到非空標頭（se_custid/ein）

在下面描述的設置中，看起來 apache 無法將所需的標頭轉發到 nginx 或 nginx，而轉發初始請求不是轉發完整的 URL，而只是轉發相對路徑。

這裡的想法是確保對託管在 nginx 上的應用程序的請求由 Azure ADFS 進行身份驗證。為此，apache 扮演任何身份驗證請求的代理角色。Apache 正在使用 mod_auth_openidc，並將未經身份驗證的請求轉發到 Azure ADFS 見下文：

Nginx -> Apache:6000-> Azure ADFS -> Apache:6000 -> Nginx

當使用者通過 Azure ADFS 正確驗證時，被重定向回 Nginx:80 但瀏覽器（由於應用程序）顯示奇怪的錯誤“在繼續請求中找不到非空標頭（se_custid/ein）”

apache日誌中的另外兩個錯誤是：

$$ auth_openidc:error $$ $$ pid 26485 $$ $$ client SERVERIP:35888 $$oidc_clean_expired_state_cookies：狀態已過期 nginx 中沒有記錄特定錯誤。

所以這裡的問題是如何將正確的標頭從 apache 轉發到 nginx，以便經過身份驗證的使用者能夠正確使用該應用程序，或者以下配置是否足夠或需要更多設置？

apache配置部分

<Location /ourapp>
  AuthType openid-connect
  Require valid-user
</Location>

LoadModule auth_openidc_module modules/mod_auth_openidc.so
OIDCProviderMetadataURL https://login.microsoftonline.com/XXXX_XXX-xxx-XXXXXX/v2.0/.well-known/openid-configuration
OIDCClientID XXXXXXXXXXXXXXX
OIDCClientSecret XXXXXXXXXX
OIDCRedirectURI https://forever-authcheck.tire1network.com:6000/ourapp 
OIDCCryptoPassphrase XXXXXXXXXXXX
OIDCScope "openid email profile"
#OIDCRemoteUserClaim email
OIDCProviderAuthorizationEndpoint https://login.microsoftonline.com/XXXX_XXX-xxx-XXXXXX/oauth2/v2.0/authorize
OIDCProviderTokenEndpoint https://login.microsoftonline.com/XXXX_XXX-xxx-XXXXXX/oauth2/v2.0/token
#OIDCPKCEMethod S256

OIDCPassIDTokenAs claims
OIDCCookiePath /
OIDCCookieDomain forever-authcheck.tire1network.com
OIDCCookie APP-OIDC-SESSION
OIDCCookieHTTPOnly On
OIDCSessionInactivityTimeout 600
OIDCSessionMaxDuration 36006

<VirtualHost *:6000>

   ProxyPreserveHost On
   ErrorLog  /var/log/httpd/voidcerror.log
   LogLevel debug
   ServerName forever-authcheck.tire1network.com

   Header always set Access-Control-Allow-Origin "*"
   Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
   Header always set Access-Control-Max-Age "1000"
   Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"
   
   ProxyPreserveHost On
   Header set ein %{OIDC_CLAIM_EIN}e
   ProxyPass /ourapp/ forever-authcheck.tire1network.com/in/
   ProxyPassReverse /ourapp/ forever-authcheck.tire1network.com/in/
   ProxyPreserveHost On
   ServerName  forever-authcheck.tire1network.com
   
   SSLEngine on
   SSLCertificateFile "/etc/pki/outcert/Certificate.pem"
   SSLCertificateKeyFile "/etc/pki/outcert/CertificateKey.pem"
   SSLCertificateChainFile "/etc/pki/outcert/CertificateChain.p12"
</VirtualHost>

nginx 配置部分

nginx:80


location /ourapp/ {
 proxy_ssl_server_name on;
 proxy_pass https://forever-authcheck.tire1network.com:6000;
 proxy_set_header se-journey "direct";
 proxy_set_header  Host $host;
 proxy_set_header  X-Real-IP $remote_addr;
 proxy_set_header  X-Forwarded-For $remote_addr;
 proxy_set_header  X-Forwarded-Host $remote_addr;
 proxy_redirect default;
 

 proxy_ssl_certificate     /etc/pki/outcert/Certificate.pem;
 proxy_ssl_certificate_key /etc/pki/outcert/CertificateKey.pem;
 proxy_ssl_verify       off;
}

好吧，圍繞理解做了一些調整，部署了另一個臨時設置來理解探勘更多日誌。

這裡是目前的理解 User Request -> Nginx:443/ourapp -> Apache:6000-> Azure ADFS -> Azure Returns URL to browser -> Browser Requests 返回的 URL

通過仔細查看日誌，很清楚發生了什麼，More over this one 幫助它更了解它

在調整 ngnix 以發送帶有埠和正確主機的正確標頭後，

proxy_set_header X-Forwarded-Port "443";

proxy_set_header X-Forwarded-Host "forever-authcheck.tire1network.com";

這導致 apache 和 mod_auth_openidc 為 original_url 設置了正確的 cookie。

現在重定向工作正常，聲明到達 NGINX 和我們的應用程序。

引用自：https://serverfault.com/questions/1099956