Apache-ს მოვთხოვოთ კლიენტის IP-ც და პროქსიში შესვლაც
Apache 2.4-ის პროქსის ავთენტიფიკაცია კლიენტის მისამართის შეზღუდვებთან დააკავშირეთ, რომ ერთმა პირობამ მარტო წვდომა არ გასცეს.
თუ Apache 2.4-ის forward პროქსიმ დამტკიცებული წყაროს მისამართიც და მოქმედი შესვლაც უნდა მოითხოვოს, გამოიყენეთ <RequireAll>:
<Proxy "*">
AuthType Basic
AuthName "Private proxy"
AuthBasicProvider file
AuthUserFile /etc/apache2/private-proxy-users
<RequireAll>
Require ip 192.0.2.25
Require valid-user
</RequireAll>
</Proxy>ეს ავტორიზაციის ფრაგმენტი არსებულ შეზღუდულ პროქსიში ჩართეთ. შეცვალეთ კლიენტის მისამართი და ანგარიშების ფაილის ბილიკი; ავთენტიფიკაციისა და ავტორიზაციის მოდულები ხელმისაწვდომი უნდა იყოს, ხოლო ფაილი უკვე უნდა შეიცავდეს საჭირო მომხმარებლებს. ეს მსმენელის სრული განთავსება არ არის.
პოლიტიკას ორი დეტალი განსაზღვრავს. კონტეინერი AND-ს გამოხატავს; დადებითი მოთხოვნების გვერდიგვერდ განთავსება ყველა მათგანს სავალდებულოს არ ხდის. Require valid-user ავთენტიფიცირებულ ანგარიშს იღებს, Require user alice კი ერთ ანგარიშს ასახელებს. ცალკე Require user არაფერს გამოხატავს. იხილეთ Apache-ს მომხმარებელთა ავტორიზაციის მითითება.
| წყარო | შესვლა | საჭირო შედეგი |
|---|---|---|
| ნებადართულია | ვარგისია | დაგეგმილი ავტორიზებული მოთხოვნა ნებადართულია. |
| ნებადართულია | აკლია ან არასწორია | ავტორიზებული გადაგზავნა არ არსებობს. |
| ნებადართულ წყაროს გარეთ | ვარგისია | ავტორიზებული გადაგზავნა არ არსებობს. |
ფრაგმენტზე დაყრდნობამდე შეამოწმეთ მისი მომცველი ვირტუალური ჰოსტი და სხვა შესაბამისი ავტორიზაციის სექციები, შემდეგ @@შეამოწმეთ ავტორიზაციის ზღვარი; უფრო კონკრეტულმა კონფიგურაციამ შეიძლება ფაქტობრივი შედეგი შეცვალოს. Basic შესვლას კლიენტსა და პროქსის შორის დაცული ტრანსპორტიც სჭირდება. დანიშნულების HTTPS მოგვიანებით იწყება და მანამდე ღია ტექსტით გადაცემულ მონაცემებს ვერ იცავს.