आपका Magento रीडायरेक्ट लूप शायद VPN नहीं है

आप एक्सेस लॉग में 302 देखते हैं, स्टोरफ़्रंट VPN से लोड नहीं होता, और निष्कर्ष स्वयं लिखा जाता है। वह निष्कर्ष आमतौर पर दिलचस्प तरीके से ग़लत होता है। रीडायरेक्ट प्रतिक्रिया उस गंतव्य को दर्ज करती है जहाँ ब्राउज़र को जाने के लिए कहा गया था, और यह नहीं बताती कि समस्या टनल, प्रमाणपत्र या एप्लिकेशन ने पैदा की। लॉग की पंक्ति जाँच की शुरुआत है, उसका निष्कर्ष नहीं।

302 बताता है कहाँ, क्यों नहीं

एक्सेस लॉग की प्रविष्टि अनुरोध, स्थिति और आकार दर्ज करती है, और आमतौर पर वह Location हेडर छोड़ देती है जो मायने रखता है। एक रीडायरेक्ट पूरी तरह सामान्य हो सकता है: विहित होस्टनाम, अंतिम स्लैश का सामान्यीकरण, HTTPS पर स्विच। आपको क्रम चाहिए, क्योंकि एक छलांग और एक लूप अलग-अलग खराबियाँ हैं, अलग-अलग मालिकों के साथ। स्कीम के बीच बार-बार छलांग URL और स्कीम हैंडलिंग की ओर संकेत करती है। लेकिन ऐसे नाम की ओर छलांग जिसे ब्राउज़र हल नहीं कर सकता, कहीं और संकेत करती है।

इनमें से कोई भी VPN के बारे में सबूत नहीं है। टनल एक मार्ग है; रीडायरेक्ट वह निर्देश है जो एप्लिकेशन ने लिखा।

श्रृंखला पकड़ें, लॉग की पंक्ति नहीं

ब्राउज़र के नेटवर्क व्यू का उपयोग करें और हर छलांग के लिए चार फ़ील्ड दर्ज करें: अनुरोधित URL, स्थिति, Location हेडर और समय। अंतिम प्रतिक्रिया या कनेक्शन त्रुटि के साथ समाप्त करें, क्योंकि दिलचस्प मामला वह छलांग है जो कभी पूरी नहीं होती। यह एक बार काम करने वाले मार्ग पर और एक बार विफल मार्ग पर करें, उसी खाते और उसी नेविगेशन के साथ। दो श्रृंखलाओं की तुलना लॉग की किसी भी एक पंक्ति से अधिक मूल्यवान है।

उस रिकॉर्ड को निजी रखें। URL सत्र पहचानकर्ता ले जाते हैं, और सहेजा गया ब्राउज़र संग्रह आपकी अपेक्षा से अधिक ले जाता है। टिकट में कुछ भी चिपकाने से पहले क्वेरी स्ट्रिंग हटा दें।

एप्लिकेशन की अपने URL के बारे में धारणा

Magento कॉन्फ़िगरेशन से निरपेक्ष URL बनाता है, प्रत्येक वेबसाइट या स्टोर व्यू के अनुसार सीमित। bin/magento config:show web/secure/base_url वह मान प्रिंट करता है जिस पर एप्लिकेशन विश्वास करता है, और वह अक्सर किसी बिल्ड या माइग्रेशन से बचा होस्टनाम होता है, न कि वह जो ब्राउज़र ने उपयोग किया। यदि वहाँ आंतरिक होस्ट का नाम है, तो ब्राउज़र को ऐसी जगह भेजा जा रहा है जहाँ वह जा नहीं सकता, और टनल में कोई भी बदलाव इसे ठीक नहीं करता।

सुरक्षित और असुरक्षित बेस URL की तुलना अपने सामने के सार्वजनिक नामों से करें। इनमें से किसी एक में असंगति ठीक वही रीडायरेक्ट पैदा करती है जिसे आप देख रहे हैं।

विश्वसनीय प्रॉक्सी हेडर एक अनुबंध हैं

जब TLS लोड बैलेंसर पर समाप्त होता है, तो एप्लिकेशन सादा HTTP देखता है और उसे अन्यथा बताना पड़ता है। ऑफ़लोडर हेडर सेटिंग उस हेडर का नाम देती है जो प्रॉक्सी सेट करता है, जैसे अग्रेषित प्रोटोकॉल, और एप्लिकेशन स्कीम निर्णयों में उस पर भरोसा करता है।

यह भरोसा एक प्रॉक्सी के साथ अनुबंध है, सामान्य अनुमति नहीं। मनमाने क्लाइंट से हेडर स्वीकार करने से कोई भी स्कीम का दावा कर सकता है, इसलिए यह केवल वहीं होना चाहिए जहाँ निर्दिष्ट प्रॉक्सी इसे सेट करता है। यदि हेडर का नाम और प्रॉक्सी का व्यवहार मेल नहीं खाते, तो एप्लिकेशन ऐसी स्कीम पर रीडायरेक्ट बनाता है जिसे ब्राउज़र ने कभी उपयोग नहीं किया, और लूप बंद हो जाता है। प्रॉक्सी कॉन्फ़िगरेशन और एप्लिकेशन सेटिंग की एक साथ जाँच करें, फिर बदलाव प्रभावी होने के लिए कॉन्फ़िगरेशन कैश फ्लश करें।

जब लूप सत्र हो, मार्ग नहीं

जो श्रृंखला हमेशा साइन-इन पर लौटती है वह आमतौर पर कुकी की समस्या है। जाँचें कि सत्र कुकी उसी होस्टनाम के लिए जारी हुई थी जो ब्राउज़र ने वास्तव में उपयोग किया, और क्या ब्राउज़र जिस कनेक्शन को सुरक्षित मानता है उस पर वह सुरक्षित चिह्नित थी। ग़लत डोमेन से बँधी कुकी ऐसा लॉगिन लूप बनाती है जो बिल्कुल रूटिंग विफलता जैसा दिखता है।

सिद्ध असंगति को उसके मालिक के पास ठीक करें, चाहे वह बेस URL हो, कुकी डोमेन हो या प्रॉक्सी अनुबंध, और फिर एक 302 के गायब होने को देखने के बजाय पूरा नेविगेशन दोबारा जाँचें। लूप तोड़ने के लिए HTTPS आवश्यकताएँ बंद करना रीडायरेक्ट को और बुरी समस्या से बदल देता है। बदलाव पूरा होने पर टनल अलग से जाँचें: कोई ज्ञात निजी संसाधन माँगें और पुष्टि करें कि वह पहुँचता है, ताकि अगले रीडायरेक्ट के पास तुलना के लिए साफ़ आधार रेखा हो।