ওয়েব-ফর্ম প্রক্সি ব্রাউজারের মূল উৎস বদলায়, শুধু এক্সিট IP নয়
URL-এন্ট্রি প্রক্সি ওয়েবসাইট আর নেটিভ ব্রাউজার প্রক্সির পার্থক্য বুঝুন এবং জটিল লগইন ও স্ক্রিপ্ট কেন আলাদা আচরণ করতে পারে তা ব্যাখ্যা করুন।
URL বাক্সসহ একটি পাতা একটি ওয়েব অ্যাপ্লিকেশন। সেখানে গন্তব্য লিখলে ওই অ্যাপ্লিকেশনকে কনটেন্ট এনে দেখাতে বলা হয়। ব্রাউজারকে HTTP বা SOCKS প্রক্সি ব্যবহার করতে বলার চেয়ে এটি ভিন্ন ব্যবস্থা।
নেটিভ প্রক্সি সেটিংয়ে ব্রাউজার গন্তব্যের URL-কে এখনও ওয়েবসাইট হিসেবেই ধরে। প্রচলিত ওয়েব-ফর্ম প্রক্সিতে দৃশ্যমান পাতাটি প্রক্সি অ্যাপ্লিকেশনের নিজের URL স্কিম ও মূল উৎসের মাধ্যমে দেওয়া হয়। সেবাটি নেভিগেশন চালু রাখতে লিংক, স্ক্রিপ্ট, হেডার বা কুকি পুনরায় লিখতে পারে।
| আচরণ | পার্থক্যটা কেন গুরুত্বপূর্ণ |
|---|---|
| একই-মূল উৎসের যাচাই | ব্রাউজার আসলে যে মূল উৎস লোড করেছে তা মূল্যায়ন করে |
| কুকি ও রিডাইরেক্ট | ডোমেইন, পাথ ও নিরাপদ প্রসঙ্গের আচরণ দেখানো URL-এর সঙ্গে মিলতে হবে |
| নতুন URL গড়া স্ক্রিপ্ট | অনুরোধ সাধারণ লিংক-পুনর্লিখন কৌশল এড়িয়ে যেতে পারে |
| স্থায়ী সংযোগ বা WebSockets | প্রক্সি অ্যাপ্লিকেশনের স্পষ্ট সামঞ্জস্যপূর্ণ হ্যান্ডলিং দরকার |
এতে একটি পরিচিত ফলাফল বোঝা যায়: সাধারণ নিবন্ধ লোড হয়, কিন্তু ডকুমেন্ট এডিটর বা লগইন প্রবাহ ব্যর্থ হয়। ব্যর্থতার মানে এই নয় যে গন্তব্য সেবার এক্সিট IP প্রত্যাখ্যান করছে। মধ্যস্থতাকারী অ্যাপ্লিকেশনের URL ও ব্রাউজার নিরাপত্তা বিষয়ক ধারণা ধরে রাখতে নাও পারে।
TLS কোথায় শেষ হয় তাও আলাদা করুন। গন্তব্যের কনটেন্ট হ্যান্ডল করা fetch-and-republish সেবা এনক্রিপ্টেড সেশন বহন করা সাধারণ CONNECT রিলের চেয়ে ভিন্ন বিশ্বাস-অবস্থানে থাকে। প্রক্সি সাইটের নিজের ঠিকানায় HTTPS দেখা ব্রাউজার থেকে মূল সাইট পর্যন্ত এন্ড-টু-এন্ড TLS সংযোগ প্রমাণ করে না।
যদি লক্ষ্য অন্য এক্সিট দিয়ে সাধারণ ব্রাউজিং হয়, তবে আপনার সেবা বা প্রক্সি তালিকা থেকে HTTP বা SOCKS এন্ডপয়েন্ট বেছে নিন এবং সমর্থিত নেটিভ প্রক্সি কনফিগারেশন ব্যবহার করুন, যেমন Firefox-এর সংযোগ সেটিংস। এটি সাধারণত ব্রাউজারের স্বাভাবিক গন্তব্য-অর্থবহতার বেশি অংশ ধরে রাখে। URL-এন্ট্রি সাইট ইচ্ছাকৃতভাবে বেছে নেওয়া অ্যাপ্লিকেশন হতে পারে, কিন্তু কম সেটআপে একই ইন্টারফেস হিসেবে উপস্থাপন করা উচিত নয়।