ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੋਂ ਪ੍ਰਮਾਣੀਕਰਨ ਚੁਣੌਤੀਆਂ ਮਿਲ ਸਕਦੀਆਂ ਹਨ: ਬੇਨਤੀ ਲੈ ਜਾਣ ਵਾਲਾ ਪਰਾਕਸੀ ਅਤੇ ਮੰਜ਼ਿਲ ਵੈੱਬਸਾਈਟ। ਉਹਨਾਂ ਨੂੰ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਇੱਕੋ ਖਾਤਾ ਨਹੀਂ ਮਿਲਣਾ ਚਾਹੀਦਾ।

Chrome ਦੀ webRequest.onAuthRequired ਘਟਨਾ ਵਿੱਚ ਲਾਭਦਾਇਕ ਭੇਦ isProxy ਹੈ। ਸਿਰਫ਼ ਪ੍ਰਾਂਪਟ ਲੁਕਾਉਣ ਲਈ ਉਹ ਜਾਂਚ ਹਟਾਉਣ ਵਾਲਾ ਕਾਲਬੈਕ ਮੂਲ ਚੁਣੌਤੀ ਨੂੰ ਪਰਾਕਸੀ ਦੇ ਪ੍ਰਮਾਣ ਦੇਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।

ਜਿਸ ਪਰਾਕਸੀ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ ਉਸ ਨਾਲ ਮਿਲਾਓ

isProxy ਦੀ ਜਾਂਚ ਕਰਨਾ ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤ ਹੈ। ਸੰਭਾਲ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਪਰਾਕਸੀ ਚੁਣੌਤੀਕਰਤਾ ਅਤੇ ਬੇਨਤੀ ਸੰਦਰਭ ਤੱਕ ਵੀ ਸੀਮਤ ਕਰੋ। ਕਈ ਐਂਡਪੌਇੰਟ ਸੰਭਾਲਣ ਵਾਲੇ ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ ਹਰ ਚੁਣੌਤੀ ਲਈ ਇੱਕ ਗਲੋਬਲ ਪਾਸਵਰਡ ਨਹੀਂ, ਸਗੋਂ ਉਸ ਐਂਡਪੌਇੰਟ ਦਾ ਖਾਤਾ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਪਰਾਕਸੀ ਰੂਟ ਸੈੱਟ ਕਰਨਾ ਅਤੇ ਉਸ ਦਾ ਲੌਗਇਨ ਸੰਭਾਲਣਾ ਇੱਕ ਇਜਾਜ਼ਤ ਜਾਂ ਇੱਕ API ਕਾਲ ਹੈ। Chrome ਇਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਘਟਨਾ ਡੇਟਾ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਇਜਾਜ਼ਤਾਂ ਲਈ ਮੌਜੂਦਾ webRequest ਹਵਾਲਾ ਵਰਤੋ। Manifest V3 ਸਰੋਤਾ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦੀ ਉਦਾਹਰਨ ਕਾਲਬੈਕ ਅੰਦਰ ਸਿੰਕ੍ਰੋਨਸ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਖਾਤਾ ਚੋਣ ਦਿਖਾਉਂਦੀ ਹੈ।

ਮੈਨੀਫੈਸਟ ਪੀੜ੍ਹੀ ਦੀ ਜਾਂਚ ਕਰੋ

ਪ੍ਰਯੋਗਾਤਮਕ WebRequest API ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀਆਂ ਉਦਾਹਰਨਾਂ ਪੁਰਾਣੇ ਐਕਸਟੈਂਸ਼ਨ ਰਿਲੀਜ਼ਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਮੌਜੂਦਾ ਇਜਾਜ਼ਤ ਲੋੜਾਂ ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਮੈਨੀਫੈਸਟ ਪੀੜ੍ਹੀ ਅਤੇ ਡਿਪਲੌਇਮੈਂਟ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਖਾਸ ਕਰਕੇ, ਪ੍ਰਮਾਣੀਕਰਨ ਸੰਭਾਲ ਦਾ ਆਪਣਾ ਸਮਰਥਿਤ ਇਜਾਜ਼ਤ ਮਾਰਗ ਹੈ; ਪੁਰਾਣੀ ਬਲਾਕਿੰਗ ਸਰੋਤਾ ਉਦਾਹਰਨ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਕਿ Manifest V3 ਐਕਸਟੈਂਸ਼ਨ ਇਸ ਨੂੰ ਬਿਨਾਂ ਬਦਲਾਅ ਚਲਾ ਸਕਦਾ ਹੈ।

ਸਹੀ ਹੈਂਡਲਰ ਨੂੰ ਉਹਨਾਂ ਹੀ ਰੱਦ ਕੀਤੇ ਪ੍ਰਮਾਣਾਂ ਨੂੰ ਅਨੰਤ ਕਾਲ ਤੱਕ ਦੁਬਾਰਾ ਅਜ਼ਮਾਉਣ ਤੋਂ ਵੀ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਖਾਤਾ ਦੇਣ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੀ ਦੂਜੀ ਚੁਣੌਤੀ ਨੂੰ ਪਾਸਵਰਡ ਨੂੰ ਸਦਾ ਲਈ ਦੁਬਾਰਾ ਵਜਾਉਣ ਦੀ ਬੇਨਤੀ ਨਹੀਂ, ਸਗੋਂ ਜਾਂਚ ਲਈ ਸਬੂਤ ਮੰਨੋ।

ਪ੍ਰਮਾਣ ਐਕਸਟੈਂਸ਼ਨ ਦੇ ਢੁੱਕਵੇਂ ਸੁਰੱਖਿਅਤ ਸੰਭਾਲ ਮਾਰਗ ਵਿੱਚ ਹੀ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ PAC ਫਾਈਲ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰੋ ਜਾਂ ਵੰਡੇ ਜਾਣ ਵਾਲੇ ਨਮੂਨੇ ਵਿੱਚ ਹਾਰਡਕੋਡ ਨਾ ਕਰੋ। ਟੀਚਾ ਸੰਕੁਚਿਤ ਦਾਇਰੇ ਦਾ ਪਰਾਕਸੀ ਲੌਗਇਨ ਹੈ, ਹਰ ਪ੍ਰਮਾਣੀਕਰਨ ਚੁਣੌਤੀ ਨੂੰ ਇੱਕੋ ਭੇਤ ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ-ਵਿਆਪੀ ਨਿਯਮ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ