Apache-ის წინა პროქსის ავტორიზაცია: Require და AuthMerging
თვალი ადევნეთ გლობალურ და ვირტუალურ ჰოსტის პროქსის ავტორიზაციას Apache-ის სექციების გაერთიანების წესებით, ნაცვლად იმისა, რომ proxy.conf ცალკე პოლიტიკის ფენად მივიჩნიოთ.
proxy.conf-ში არსებული წესი წესების განსაკუთრებული კლასი არ არის. Apache ჩართულ კონფიგურაციას თავის კონფიგურაციის ხეში კითხულობს; მომცველი გლობალური, VirtualHost ან შესაბამისი სექცია განსაზღვრავს, როგორ მონაწილეობს დირექტივა.
დაიწყეთ იმ ლისენერითა და ვირტუალური ჰოსტით, რომლებიც წინა პროქსის მოთხოვნას ემსახურებიან. შემდეგ შეაგროვეთ შესაბამისი Proxy სექციები ამ კონტექსტიდან და მთავარი კონფიგურაციიდან. მნიშვნელოვანია სექციების დამუშავების რიგი და არა მხოლოდ ის, თუ რომელი ფაილი შეიცვალა ბოლოს.
ავტორიზაცია ყოველთვის კუმულაციური არ არის
ნაგულისხმევი AuthMerging Off ქცევით ავტორიზაცია მემკვიდრეობით გადადის მანამ, სანამ უფრო გვიანდელი მოქმედი სექცია საკუთარ ავტორიზაციის ლოგიკას მოგვცემს. ეს ახალი ლოგიკა შეიძლება წინა მოთხოვნები ჩაანაცვლოს, ნაცვლად კიდევ ერთი შეზღუდვის დამატებისა.
| პარამეტრი | კომბინაცია უახლოეს წინა ავტორიზაციის სექციასთან |
|---|---|
| Off | ახალ ავტორიზაციას შეუძლია მემკვიდრეობით მიღებული ლოგიკის გადაფარვა |
| And | ორივე ნაკრებმა უნდა მისცეს ავტორიზაცია |
| Or | ნებისმიერ ნაკრებს შეუძლია ავტორიზაციის მიცემა |
თავად AuthMerging ლოკალურია იმ სექციისთვის, რომელიც მას შეიცავს. ნუ ჩათვლით, რომ And-ის ერთხელ დაყენება ყველა შემდგომ სექციას შეცვლის.
სადაც შესაძლებელია, სასურველი პოლიტიკა ცხადად შეინახეთ. ორი Require ხაზი მომცველი ავტორიზაციის კონტეინერის გარეშე ნაგულისხმევად ალტერნატივებია, ამიტომ IP წესი პლუს valid-user ავტომატურად „IP და მომხმარებელი“ არ არის. გამოიყენეთ RequireAll, როცა ორივე პირობა ერთ გადაწყვეტილებას განეკუთვნება.
სანამ პროქსის ანგარიშს შეცვლით ან წვდომას გახსნით, გადახედეთ სრულ შესაბამის კონფიგურაციას. შემდეგ მოქმედი ლისენერის წინააღმდეგ შეამოწმეთ დაშვებული და უარყოფილი შემთხვევები. მოთხოვნა შეიძლება უარყოფილ იქნას—ან მოულოდნელად დაიშვას—რადგან ეფექტური ავტორიზაცია სხვა სექციამ მოგვცა.