तुमचा 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 आवश्यकता बंद करणे हे रीडायरेक्टच्या बदल्यात अधिक वाईट समस्या आणते। बदल झाल्यावर टनेल स्वतंत्रपणे तपासा: ज्ञात खाजगी संसाधनाची विनंती करा आणि ते पोहोचते याची खात्री करा, जेणेकरून पुढील रीडायरेक्टला तुलना करण्यासाठी स्वच्छ आधाररेषा असेल।