আপনার 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-এর প্রয়োজনীয়তা বন্ধ করা একটি রিডাইরেক্টের বদলে আরও খারাপ সমস্যা ডেকে আনে। পরিবর্তন শেষ হলে টানেলটি আলাদাভাবে যাচাই করুন: একটি পরিচিত ব্যক্তিগত রিসোর্স অনুরোধ করুন এবং তা পৌঁছায় কি না নিশ্চিত করুন, যাতে পরের রিডাইরেক্টের তুলনার জন্য পরিষ্কার ভিত্তি থাকে।