კლიენტს შეუძლია 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 თავსართი ცალკე გაცვლად რჩება.

დაკავშირებული სტატიები