Apache-ի ուղղորդող պրոքսիի լիազորում՝ Require և AuthMerging
Հետևե՛ք գլոբալ և վիրտուալ հոսթի պրոքսիի լիազորմանը Apache-ի բաժինների միաձուլման կանոններով՝ proxy.conf-ը որպես առանձին քաղաքականության շերտ չդիտարկելով։
proxy.conf-ում կանոնը հատուկ կանոնի դաս չէ։ Apache-ը ներառված կոնֆիգուրացիան կարդում է իր կոնֆիգուրացիայի ծառի մեջ. շրջապատող գլոբալ, VirtualHost կամ համապատասխան բաժինը որոշում է, թե ինչպես է հրահանգը մասնակցում։
Սկսե՛ք ուղղորդող պրոքսիի հարցումը սպասարկող լսողից և վիրտուալ հոսթից։ Այնուհետև հավաքե՛ք համապատասխան Proxy բաժինները այդ համատեքստից և հիմնական կոնֆիգուրացիայից։ Կարևոր է բաժինների մշակման հերթականությունը, ոչ միայն այն, թե որ ֆայլն է վերջին խմբագրվել։
Լիազորումը միշտ չէ, որ կուտակային է
Լռելյայն AuthMerging Off վարքով լիազորումը ժառանգվում է, քանի դեռ ավելի ուշ կիրառելի բաժինը չի տրամադրում իր սեփական լիազորման տրամաբանությունը։ Այդ նոր տրամաբանությունը կարող է փոխարինել նախորդ պահանջները՝ փոխարենը ևս մեկ սահմանափակում ավելացնելու։
| Կարգավորում | Համակցում մոտակա նախորդ լիազորման բաժնի հետ |
|---|---|
| Off | Նոր լիազորումը կարող է վերացնել ժառանգված տրամաբանությունը |
| And | Երկու հավաքածուներն էլ պետք է լիազորեն |
| Or | Հավաքածուներից ցանկացածը կարող է լիազորել |
AuthMerging-ն ինքնին տեղայնացված է այն պարունակող բաժնում։ Մի՛ ենթադրեք, որ And-ը մեկ անգամ դնելը փոխում է յուրաքանչյուր հաջորդ բաժին։
Հնարավորության դեպքում նախատեսված քաղաքականությունը պահե՛ք բացահայտ։ Շրջապատող լիազորման տարայով չփակված երկու Require տողերը ենթադրաբար այլընտրանքներ են, ուստի IP կանոնը գումարած valid-user-ը ինքնաբերաբար «IP և օգտատեր» չէ։ Օգտագործե՛ք RequireAll, երբ երկու պայմանները պատկանում են նույն որոշմանը։
Վերանայե՛ք ամբողջական համապատասխան կոնֆիգուրացիան՝ նախքան պրոքսիի հաշիվը փոխելը կամ հասանելիությունը բացելը։ Այնուհետև փորձարկե՛ք թույլատրված և մերժված դեպքերը աշխատող լսողի դեմ։ Հարցումը կարող է մերժվել—կամ անսպասելիորեն թույլատրվել—որովհետև մեկ այլ բաժին է տրամադրել գործող լիազորումը։