ਪ੍ਰੌਕਸੀ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਿਨਾਂ ਇੱਕ Squid ਮੰਜ਼ਿਲ ਦੀ ਆਗਿਆ ਦਿਓ

ਮਾਨੀਟਰਿੰਗ ਸਫ਼ੇ ਨੂੰ ਪ੍ਰੌਕਸੀ ਲੌਗਇਨ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਪਸ਼ਟ ਨਿਯਮ http_access allow status_site ਹੈ। ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖਿਆ ਜਾਵੇ, ਤਾਂ ਇਹ ਉਨ੍ਹਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਵੀ ਅਪਵਾਦ ਦੇ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਦਾ ਤੁਸੀਂ ਕਦੇ ਇਰਾਦਾ ਨਹੀਂ ਸੀ ਰੱਖਿਆ।

Squid 6 ਜਾਂ 7 ਲਈ, ਅਪਵਾਦ ਦੀਆਂ ਸ਼ਰਤਾਂ ਇਕੱਠੀਆਂ ਰੱਖੋ। ਮੌਜੂਦਾ ਪ੍ਰਬੰਧਨ, ਅਸੁਰੱਖਿਅਤ ਪੋਰਟ, CONNECT ਅਤੇ ਸਥਾਨਕ-ਸੇਵਾ ਸੁਰੱਖਿਆਵਾਂ ਤੋਂ ਬਾਅਦ, ਸੰਬੰਧਿਤ ਹਿੱਸਾ ਇੰਝ ਦਿਖ ਸਕਦਾ ਹੈ:

acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED

http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all

ਨੈੱਟਵਰਕ ਅਤੇ ਹੋਸਟਨਾਮ ਪਲੇਸਹੋਲਡਰ ਹਨ। ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਅਜੇ ਵੀ ਆਪਣੀ ਮੌਜੂਦਾ ਹੈਲਪਰ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਕਿਸੇ ਪਹੁੰਚ ਨੀਤੀ ਦਾ ਅਪਵਾਦ ਹਿੱਸਾ ਹੈ, ਪੂਰੀ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਨਹੀਂ।

ਪਹਿਲੀ ਲਾਈਨ ਚੁਣੇ ਹੋਏ ਕਲਾਇੰਟਾਂ ਨੂੰ ਲੌਗਇਨ ACL ਦਾ ਮੁਲਾਂਕਣ ਕੀਤੇ ਬਿਨਾਂ ਉਸ ਮੰਜ਼ਿਲ ਤੱਕ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਅਗਲੀ ਲਾਈਨ ਉਨ੍ਹਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਹੋਰ ਥਾਵਾਂ 'ਤੇ ਕੇਵਲ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਾਅਦ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਦੀਆਂ ਵਿਆਪਕ ਆਗਿਆਵਾਂ ਜਾਂ ਬਾਅਦ ਦੇ ਵਿਕਲਪਕ ਰਸਤੇ ਨਤੀਜਾ ਬਦਲ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਫ਼ਾਈਲਾਂ ਸਮੇਤ ਪੂਰੀ ਕ੍ਰਮਬੱਧ ਨੀਤੀ ਪੜ੍ਹੋ।

ਕੇਵਲ ਪ੍ਰੌਂਪਟ ਤੋਂ ਬਚਣ ਲਈ ਅਪਵਾਦ ਨੂੰ ਮੰਜ਼ਿਲ-ਪੋਰਟ ਸੁਰੱਖਿਆਵਾਂ ਉੱਪਰ ਨਾ ਲੈ ਜਾਓ। ਅਣਚਾਹੇ ਪੋਰਟ 'ਤੇ ਅਧਿਕ੍ਰਿਤ ਸਾਈਟ ਅਜੇ ਵੀ ਇੱਕ ਵੱਖਰਾ ਰਸਤਾ ਹੈ। ਇਹ ਵੀ ਤੈਅ ਕਰੋ ਕਿ ਸਹੀ ਹੋਸਟ ਜਾਂ ਇਸ ਦੇ ਸਬਡੋਮੇਨ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਬੇਲੋੜੀ ਵਿਆਪਕ ਪਿਛੇਤਰ ਜੋੜਨ ਦੀ ਬਜਾਏ।

ਹੋਸਟਨਾਮ ਅਪਵਾਦ ਮੇਲ ਖਾਂਦੀ ਮੰਜ਼ਿਲ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਇਸ ਦੇ ਸਫ਼ੇ ਵੱਲੋਂ ਲੋਡ ਹੋਣ ਵਾਲੀ ਹਰ ਨਿਰਭਰਤਾ ਨੂੰ ਨਹੀਂ। ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੰਪਤੀਆਂ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਆਮ ਲੌਗਇਨ ਲੋੜ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਸਾਧਾਰਨ HTTP ਲਈ, ਪ੍ਰੌਕਸੀ ਜਿੱਥੇ ਢੁਕਵਾਂ ਹੋਵੇ ਵਧੇਰੇ ਸੂਖਮ URL ਜਾਣਕਾਰੀ ਵਰਤ ਸਕਦੀ ਹੈ। ਆਮ HTTPS CONNECT ਬੇਨਤੀ ਸਫ਼ੇ ਦਾ ਰਾਹ ਜ਼ਾਹਰ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਲਈ ਪੂਰੇ ਹੋਸਟ ਲਈ ਟਨਲ ਅਪਵਾਦ ਤੋਂ 'ਕੇਵਲ ਇੱਕ ਸਫ਼ਾ' ਨਿਯਮ ਦਾ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ।