حلقهٔ تغییرمسیر 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 ساده می‌بیند و باید خلاف آن به آن گفته شود. تنظیم سرآیند offloader نام سرآیندی را می‌گوید که پروکسی تعیین می‌کند، مانند پروتکل ارسال‌شده، و برنامه در تصمیم‌های طرح به آن اعتماد می‌کند.

این اعتماد قراردادی با یک پروکسی است، نه اجازه‌ای عمومی. پذیرفتن سرآیند از کارخواهان دلبخواه به هر کسی اجازه می‌دهد طرحی را ادعا کند، از همین رو فقط جایی جای دارد که پروکسی مشخصی آن را تعیین می‌کند. اگر نام سرآیند و رفتار پروکسی ناهمخوان باشند، برنامه تغییرمسیرهایی به طرحی می‌سازد که مرورگر هرگز استفاده نکرده و حلقه بسته می‌شود. پیکربندی پروکسی و تنظیم برنامه را با هم بررسی کنید، سپس حافظهٔ نهان پیکربندی را خالی کنید تا تغییر اثر کند.

وقتی حلقه یک نشست است، نه یک مسیر

زنجیره‌ای که همیشه به ورود بازمی‌گردد معمولاً مشکل کوکی است. بررسی کنید که کوکی نشست برای نام میزبانی صادر شده باشد که مرورگر واقعاً استفاده کرده، و اینکه در اتصالی که مرورگر آن را امن می‌داند، امن علامت خورده باشد. کوکی محدودشده به دامنهٔ اشتباه حلقهٔ ورودی می‌سازد که دقیقاً شبیه شکست مسیریابی است.

ناهمخوانی اثبات‌شده را نزد مالکش برطرف کنید، چه URL پایه باشد، چه دامنهٔ کوکی یا قرارداد پروکسی، سپس کل گشت‌وگذار را دوباره بیازمایید نه اینکه تماشا کنید یک 302 ناپدید می‌شود. خاموش‌کردن الزامات HTTPS برای شکستن حلقه، یک تغییرمسیر را با مشکلی بدتر معاوضه می‌کند. وقتی تغییر انجام شد، تونل را جداگانه بررسی کنید: یک منبع خصوصی شناخته‌شده را درخواست کنید و تأیید کنید که می‌رسد، تا تغییرمسیر بعدی خط پایهٔ تمیزی برای مقایسه داشته باشد.