Apache ProxyRemote শংসাপত্র বনাম proxy-chain-auth

একটি ক্লায়েন্ট একটি অ্যাকাউন্ট দিয়ে Apache ফরওয়ার্ড প্রক্সিতে প্রমাণীকৃত হতে পারে, আর Apache অন্য একটি অ্যাকাউন্ট দিয়ে প্যারেন্ট প্রক্সিতে প্রমাণীকৃত হয়:

client ── client account ── Apache ── parent account ── parent proxy

httpd 2.4.59 বা তার পরের সংস্করণে নির্দিষ্ট প্যারেন্ট অ্যাকাউন্টের জন্য ProxyRemote একটি তৃতীয় আর্গুমেন্ট গ্রহণ করে:

ProxyRemote "*" "http://parent.example:3128" "parent-user:replace_with_private_password"

এটি বিদ্যমান অ্যাক্সেস-নিয়ন্ত্রিত ফরওয়ার্ড-প্রক্সি কনফিগারেশনের পরিপূরক, যেমন একটি প্রাইভেট লিসেনার যা ক্লায়েন্ট IP এবং প্রক্সি লগইন দুটোই প্রয়োজন করে। অ্যাকাউন্টটি নির্বাচিত প্যারেন্টের। এটি ধারণকারী কনফিগারেশন সুরক্ষিত করুন এবং ডিপ্লয়মেন্টের প্রয়োজনীয় মিলের পরিসর বেছে নিন।

Apache এই Basic শংসাপত্রগুলো আগেভাগে পাঠায়, প্রথমে চ্যালেঞ্জের জন্য অপেক্ষা না করে। ফলে প্যারেন্ট সংযোগের পরিবহন ও অ্যাকাউন্ট নীতি গুরুত্বপূর্ণ হয়ে ওঠে; সাইটের পরবর্তী HTTPS সেশন নিজে প্যারেন্টের দিকে একটি স্পষ্টপাঠ্য HTTP হপ রক্ষা করে না।

একই আগত অ্যাকাউন্ট কখন এগিয়ে যাওয়া উচিত

Apache সাধারণত নিজের প্রতি লক্ষ্য করা প্রক্সি প্রমাণীকরণ গ্রহণ করে। proxy-chain-auth পরিবেশ সেটিং বদলে ক্লায়েন্টের প্রক্সি শংসাপত্র পরবর্তী প্রক্সিতে পাঠানোর অনুমতি দেয়:

SetEnv proxy-chain-auth On

এটি কেবল ইচ্ছাকৃতভাবে ভাগ করা প্রমাণীকরণ শৃঙ্খলের জন্য উপযুক্ত। এটি আগত অ্যাকাউন্টের উপাদান এগিয়ে দেয়; এটি ভিন্ন প্যারেন্ট ব্যবহারকারীনাম ও পাসওয়ার্ড তৈরি করে না।

ProxyRemote-এর স্পষ্ট শংসাপত্র আর্গুমেন্ট থাকলে proxy-chain-auth-এর কোনো প্রভাব নেই। কোন পাসওয়ার্ড কাজ করবে সেই আশায় দুটি সেটিং স্তরে না রেখে শংসাপত্রের উৎস সচেতনভাবে বেছে নিন।

এই প্রক্রিয়াগুলো প্রক্সি হপ প্রমাণীকৃত করে। গন্তব্য সাইটের Authorization হেডার আলাদা একটি বিনিময়ই থাকে।