حلقة إعادة التوجيه في 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 لكسر الحلقة يقايض إعادة توجيه بمشكلة أسوأ. وعند انتهاء التغيير، افحص النفق بشكل منفصل: اطلب موردًا خاصًا معروفًا وتأكد من وصوله، حتى يكون لإعادة التوجيه التالية خط أساس نظيف للمقارنة.