Apache ફોરવર્ડ પ્રોક્સી ઑથરાઇઝેશન: Require અને AuthMerging
proxy.confને અલગ પૉલિસી સ્તર તરીકે ગણવાને બદલે Apacheના સેક્શન-મર્જિંગ નિયમો દ્વારા વૈશ્વિક અને વર્ચ્યુઅલ-હોસ્ટ પ્રોક્સી ઑથરાઇઝેશનને અનુસરો.
proxy.confમાંનો નિયમ કોઈ વિશેષ પ્રકારનો નિયમ નથી. Apache સમાવિષ્ટ કૉન્ફિગરેશનને તેના કૉન્ફિગરેશન ટ્રીમાં વાંચે છે; આવરી લેતો વૈશ્વિક, VirtualHost અથવા મેળ ખાતો સેક્શન નક્કી કરે છે કે ડિરેક્ટિવ કેવી રીતે ભાગ લે છે.
ફોરવર્ડ-પ્રોક્સી વિનંતી પરસેવા કરતા લિસનર અને વર્ચ્યુઅલ હોસ્ટથી શરૂ કરો. પછી તે સંદર્ભ અને મુખ્ય કૉન્ફિગરેશનમાંથી મેળ ખાતા Proxy સેક્શન એકત્રિત કરો. સેક્શન પ્રોસેસિંગનો ક્રમ મહત્ત્વનો છે, ફક્ત કઈ ફાઇલ છેલ્લે સંપાદિત થઈ તે નહીં.
ઑથરાઇઝેશન હંમેશા સંચયી નથી
ડિફૉલ્ટ AuthMerging Off વર્તન સાથે, ઑથરાઇઝેશન ત્યાં સુધી વારસાગત રહે છે જ્યાં સુધી પછીનું લાગુ પડતું સેક્શન તેનું પોતાનું ઑથરાઇઝેશન લૉજિક આપે. તે નવું લૉજિક બીજી મર્યાદા ઉમેરવાને બદલે અગાઉની આવશ્યકતાઓને બદલી શકે છે.
| સેટિંગ | નજીકના અગાઉના ઑથરાઇઝેશન સેક્શન સાથે સંયોજન |
|---|---|
| Off | નવું ઑથરાઇઝેશન વારસાગત લૉજિકને ઓવરરાઇડ કરી શકે છે |
| And | બંને સેટે ઑથરાઇઝ કરવું પડે |
| Or | કોઈપણ એક સેટ ઑથરાઇઝ કરી શકે |
AuthMerging પોતે જે સેક્શનમાં છે તેના પૂરતું સ્થાનિક છે. એવું ન ધારો કે એક વાર And સેટ કરવાથી દરેક પછીનું સેક્શન બદલાઈ જાય છે.
જ્યાં શક્ય હોય ત્યાં ઇચ્છિત પૉલિસી સ્પષ્ટ રાખો. આવરી લેતા ઑથરાઇઝેશન કન્ટેનર વિનાની બે Require લાઇનો ગર્ભિત રીતે વિકલ્પો છે, તેથી IP નિયમ સાથે valid-user આપોઆપ “IP અને વપરાશકર્તા” નથી. વાપરો બંને શરતો એક જ નિર્ણયની હોય ત્યારે RequireAll.
પ્રોક્સી ખાતું બદલતા કે ઍક્સેસ ખોલતા પહેલાં સંપૂર્ણ મેળ ખાતું કૉન્ફિગરેશન સમીક્ષા કરો. પછી ચાલુ લિસનર સામે મંજૂર અને નકારાયેલા કેસોની કસોટી કરો. વિનંતી નકારી શકાય છે—અથવા અણધારી રીતે મંજૂર થઈ શકે છે—કારણ કે બીજા સેક્શને અસરકારક ઑથરાઇઝેશન પૂરું પાડ્યું છે.