Apache ਫ਼ਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਅਧਿਕਾਰ: Require ਅਤੇ AuthMerging
proxy.conf ਨੂੰ ਵੱਖਰੀ ਨੀਤੀ ਪਰਤ ਮੰਨਣ ਦੀ ਥਾਂ Apache ਦੇ ਸੈਕਸ਼ਨ-ਮਿਲਾਉਣ ਨਿਯਮਾਂ ਰਾਹੀਂ ਗਲੋਬਲ ਅਤੇ ਵਰਚੁਅਲ-ਹੋਸਟ ਪ੍ਰੌਕਸੀ ਅਧਿਕਾਰ ਦੀ ਪੈੜ ਲਵੋ।
proxy.conf ਵਿੱਚਲਾ ਨਿਯਮ ਕੋਈ ਖ਼ਾਸ ਨਿਯਮ ਵਰਗ ਨਹੀਂ ਹੈ। Apache ਸ਼ਾਮਲ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ ਆਪਣੇ ਸੰਰਚਨਾ ਦਰਖ਼ਤ ਵਿੱਚ ਪੜ੍ਹਦਾ ਹੈ; ਘੇਰਨ ਵਾਲਾ ਗਲੋਬਲ, VirtualHost ਜਾਂ ਮਿਲਦਾ ਸੈਕਸ਼ਨ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਨਿਰਦੇਸ਼ ਕਿਵੇਂ ਹਿੱਸਾ ਲੈਂਦਾ ਹੈ।
ਫ਼ਾਰਵਰਡ-ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਲਿਸਨਰ ਅਤੇ ਵਰਚੁਅਲ ਹੋਸਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ ਉਸ ਸੰਦਰਭ ਅਤੇ ਮੁੱਖ ਸੰਰਚਨਾ ਤੋਂ ਮਿਲਦੇ Proxy ਸੈਕਸ਼ਨ ਇਕੱਠੇ ਕਰੋ। ਸੈਕਸ਼ਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜੀ ਫਾਈਲ ਆਖ਼ਰ ਵਿੱਚ ਸੋਧੀ ਗਈ।
ਅਧਿਕਾਰ ਹਮੇਸ਼ਾ ਜੋੜੀਦਾਰ ਨਹੀਂ ਹੁੰਦਾ
ਡਿਫ਼ਾਲਟ AuthMerging Off ਵਿਵਹਾਰ ਨਾਲ, ਅਧਿਕਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਬਾਅਦ ਵਾਲਾ ਲਾਗੂ ਸੈਕਸ਼ਨ ਆਪਣਾ ਅਧਿਕਾਰ ਤਰਕ ਨਹੀਂ ਦਿੰਦਾ। ਉਹ ਨਵਾਂ ਤਰਕ ਇੱਕ ਹੋਰ ਪਾਬੰਦੀ ਜੋੜਨ ਦੀ ਥਾਂ ਪਿਛਲੀਆਂ ਲੋੜਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
| ਸੈਟਿੰਗ | ਸਭ ਤੋਂ ਨੇੜਲੇ ਪਿਛਲੇ ਅਧਿਕਾਰ ਸੈਕਸ਼ਨ ਨਾਲ ਸੰਯੋਜਨ |
|---|---|
| Off | ਨਵਾਂ ਅਧਿਕਾਰ ਵਿਰਾਸਤੀ ਤਰਕ ਨੂੰ ਪਛਾੜ ਸਕਦਾ ਹੈ |
| And | ਦੋਵੇਂ ਸੈਟਾਂ ਨੂੰ ਅਧਿਕਾਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ |
| Or | ਕੋਈ ਵੀ ਸੈਟ ਅਧਿਕਾਰ ਦੇ ਸਕਦੀ ਹੈ |
AuthMerging ਆਪਣੇ ਆਪ ਵਿੱਚ ਉਸੇ ਸੈਕਸ਼ਨ ਤੱਕ ਸੀਮਤ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਹੈ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਇੱਕ ਵਾਰ And ਸੈੱਟ ਕਰਨ ਨਾਲ ਹਰ ਬਾਅਦ ਵਾਲਾ ਸੈਕਸ਼ਨ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਇੱਛਤ ਨੀਤੀ ਸਪਸ਼ਟ ਰੱਖੋ। ਘੇਰਨ ਵਾਲੇ ਅਧਿਕਾਰ ਕੰਟੇਨਰ ਤੋਂ ਬਿਨਾਂ ਦੋ Require ਲਾਈਨਾਂ ਅੰਤਰਨਿਹਿਤ ਰੂਪ ਵਿੱਚ ਬਦਲ ਹਨ, ਇਸ ਲਈ IP ਨਿਯਮ ਅਤੇ valid-user ਆਪਣੇ ਆਪ “IP ਅਤੇ ਵਰਤੋਂਕਾਰ” ਨਹੀਂ ਹੁੰਦੇ। ਵਰਤੋ ਜਦੋਂ ਦੋਵੇਂ ਸ਼ਰਤਾਂ ਇੱਕੋ ਫ਼ੈਸਲੇ ਦੀਆਂ ਹੋਣ ਤਾਂ RequireAll.
ਪ੍ਰੌਕਸੀ ਖਾਤਾ ਬਦਲਣ ਜਾਂ ਪਹੁੰਚ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੀ ਮਿਲਦੀ ਸੰਰਚਨਾ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਫਿਰ ਚੱਲ ਰਹੇ ਲਿਸਨਰ ਦੇ ਵਿਰੁੱਧ ਮਨਜ਼ੂਰ ਅਤੇ ਰੱਦ ਕੀਤੇ ਕੇਸਾਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਕੋਈ ਬੇਨਤੀ ਰੱਦ ਹੋ ਸਕਦੀ ਹੈ—ਜਾਂ ਅਚਾਨਕ ਮਨਜ਼ੂਰ—ਕਿਉਂਕਿ ਕਿਸੇ ਹੋਰ ਸੈਕਸ਼ਨ ਨੇ ਪ੍ਰਭਾਵੀ ਅਧਿਕਾਰ ਦਿੱਤਾ ਹੈ।