في الإعداد الموضح أدناه ، يبدو أن apache غير قادر على إعادة توجيه الرؤوس المطلوبة إلى nginx أو nginx أثناء إعادة توجيه الطلب الأولي لا يعيد توجيه عنوان URL الكامل ولكن المسار النسبي فقط.

الفكرة هنا هي التأكد من مصادقة Azure ADFS على طلب التطبيق المستضاف على nginx. لكي يعمل هذا ، يلعب أباتشي دور الوكيل لأي طلبات مصادقة. يستخدم Apache mod_auth_openidc ويعيد توجيه الطلب غير المصدق إلى Azure ADFS انظر أدناه:

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

بينما يتم مصادقة المستخدم بشكل صحيح بواسطة Azure ADFS ، تتم إعادة توجيهه مرة أخرى إلى Nginx: 80 ولكن المتصفح (بسبب التطبيق) يعرض خطأً غريبًا "عنوان غير فارغ (se_custid / ein) غير موجود في طلب المتابعة"

هناك خطأان آخران في سجل اباتشي هما:

[auth_openidc: error] [pid 26485] [client SERVERIP: 35888] oidc_clean_expired_state_cookies: الحالة منتهية

لم يتم تسجيل أخطاء محددة في nginx.

لذا فإن السؤال هنا هو كيفية إعادة توجيه الرؤوس الصحيحة من apache إلى nginx حتى يتمكن مستخدم ما بعد المصادقة من استخدام التطبيق بشكل صحيح أم أن التهيئة أدناه كافية أم أن هناك حاجة إلى مزيد من الإعدادات؟

جزء التكوين اباتشي

<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;
}









answer

حسنًا ، لقد تم إجراء القليل من البحث حول الفهم ، ونشر إعدادًا مؤقتًا آخر لفهم حفر المزيد من السجلات.

إليك فهم طلب المستخدم الحالي -> Nginx: 443 / ourapp -> Apache: 6000-> Azure ADFS -> Azure إرجاع عنوان URL إلى المتصفح -> يطلب المستعرض عنوان URL الذي تم إرجاعه

من خلال النظر في السجلات عن كثب ، كان من الواضح ما يحدث ، وساعده المزيد على فهمه أكثر

بعد التغيير والتبديل في ngnix لإرسال الرؤوس اليمنى مع المنفذ والمضيف الصحيح ،

proxy_set_header X-Forwarded-Port "443";

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

مما أدى إلى إعدادات ملفات تعريف الارتباط الصحيحة لـ original_url ، بواسطة apache و mod_auth_openidc.

الآن تعمل إعادة التوجيه بشكل صحيح ، وتصل المطالبات إلى NGINX وتطبيقنا.