Playwright ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੈੱਬ-ਸਕ੍ਰੇਪਿੰਗ (web-scraping) ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਪਹਿਲੀ ਬੇਨਤੀ (request) ਹੀ ਰੱਦ ਹੋ ਰਹੀ ਹੈ, ਭਾਵੇਂ ਕਿ ਸਕ੍ਰਿਪਟ ਇੱਕ ਪੂਰਾ Chromium ਇੰਸਟੈਂਸ ਲਾਂਚ ਕਰਦੀ ਹੈ, ਇੱਕ ਅਸਲੀ User-Agent ਸੈੱਟ ਕਰਦੀ ਹੈ ਅਤੇ ਮਨੁੱਖੀ ਵਰਗੇ ਡਿਲੇ (delays) ਪਾਉਂਦੀ ਹੈ। ਸਰਵਰ TLS ਹੈਂਡਸ਼ੇਕ (handshake) ਦੌਰਾਨ ਬੇਨਤੀ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨੂੰ TLS ਫਿੰਗਰਪ੍ਰਿੰਟਿੰਗ (TLS fingerprinting) ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
TLS ਫਿੰਗਰਪ੍ਰਿੰਟਿੰਗ ਦੀ ਵਿਆਖਿਆ
ਜਦੋਂ ਕੋਈ ਬ੍ਰਾਊਜ਼ਰ HTTPS ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ClientHello ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ। ਪੈਕੇਟ ਵਿੱਚ TLS ਵਰਜ਼ਨ, ਸਮਰਥਿਤ ਸਾਈਫਰ ਸੂਟਸ (cipher suites), ਐਕਸਟੈਂਸ਼ਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ (elliptic curves, signature algorithms) ਅਤੇ ਕੁਝ ਹੋਰ ਫੀਲਡਾਂ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਸਹੀ ਸੁਮੇਲ ਨੈੱਟਵਰਕਿੰਗ ਸਟੈਕ ਦੀ ਵਿਲੱਖਣ ਪਛਾਣ ਕਰਦਾ ਹੈ।
ਖੋਜਕਰਤਾ ਉਹਨਾਂ ਕੱਚੇ (raw) ਫੀਲਡਾਂ ਨੂੰ ਇੱਕ ਸੰਖੇਪ ਪਛਾਣਕਰਤਾ ਵਿੱਚ ਹੈਸ਼ (hash) ਕਰਦੇ ਹਨ ਜਿਸ ਨੂੰ JA3 (ਜਾਂ ਇਸ ਦਾ ਨਵਾਂ ਰਿਸ਼ਤੇਦਾਰ JA4) ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਅਸਲੀ Chrome ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਹੈਸ਼ ਬਣਾਉਂਦਾ ਹੈ; ਇੱਕ Python HTTP ਲਾਇਬ੍ਰੇਰੀ ਦੂਜਾ ਬਣਾਉਂਦੀ ਹੈ। ਜੇਕਰ ਸਰਵਰ ਦਾ ਹੈਸ਼ ਦਾਅਵਾ ਕੀਤੇ User-Agent ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਤਾਂ ਇਹ ਬੇਨਤੀ ਨੂੰ ਸਕ੍ਰਿਪਟਡ (scripted) ਵਜੋਂ ਫਲੈਗ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਸਾਧਾਰਨ (vanilla) Playwright ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਫਿਰ ਵੀ ਕਿਉਂ ਫਲੈਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ
Playwright ਦਾ ਡਿਫੌਲਟ Chromium ਬਿਲਡ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ Chrome ਫਿੰਗਰਪ੍ਰਿੰਟ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਸਕ੍ਰੈਪਰ ਅਜਿਹੇ ਕਦਮ ਜੋੜਦੇ ਹਨ ਜੋ ਇਕਸਾਰਤਾ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ:
- ਮਿਸ਼ਰਤ ਬੇਨਤੀ ਰਣਨੀਤੀਆਂ (Mixed request strategies) – ਡਿਵੈਲਪਰ ਅਕਸਰ Playwright ਨੂੰ ਭਾਰੀ ਪੇਜ ਰੈਂਡਰ ਕਰਨ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਇੱਕ ਹਲਕਾ HTTP ਕਲਾਇੰਟ ਸਹਾਇਕ ਸਰੋਤ (JSON, ਚਿੱਤਰ, ਆਦਿ) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਉਹ ਤੇਜ਼ ਕਾਲਾਂ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਫਿੰਗਰਪ੍ਰਿੰਟ ਲੈ ਕੇ ਜਾਂਦੀਆਂ ਹਨ, Chrome ਦਾ ਨਹੀਂ, ਅਤੇ ਸਰਵਰ ਤੁਰੰਤ ਇਸ ਅਸਮਾਨਤਾ ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ।
- TLS-terminating ਪ੍ਰੌਕਸੀਆਂ – ਕੁਝ ਪ੍ਰੌਕਸੀ ਸੇਵਾਵਾਂ TLS ਸਟ੍ਰੀਮ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦੀਆਂ ਹਨ, ਟ੍ਰੈਫਿਕ ਦੀ ਜਾਂਚ ਜਾਂ ਸੋਧ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਐਨਕ੍ਰਿਪਟ ਕਰਦੀਆਂ ਹਨ। ਸਰਵਰ ਅੰਤ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਦਾ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੇਖਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਨਾਨ-ਬ੍ਰਾਊਜ਼ਰ ਕਲਾਇੰਟ ਵਜੋਂ ਬਲੌਕ ਕਰ ਸਕਦਾ ਹੈ।
- ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਲੇਅਰਾਂ – ਐਂਟੀ-ਸਕ੍ਰੇਪਿੰਗ ਪ੍ਰਣਾਲੀਆਂ HTTP/2 ਸੈਟਿੰਗਾਂ, ਹੈਡਰ ਦੇ ਕ੍ਰਮ, ਅਤੇ IP ਸਾਖ (reputation) ਦੀ ਵੀ ਤੁਲਨਾ ਕਰਦੀਆਂ ਹਨ। ਕਿਸੇ ਵੀ ਲੇਅਰ ਵਿੱਚ ਅਸਮਾਨਤਾ ਬਲੌਕ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੀ ਹੈ।
JA3 ਤੋਂ JA4 ਤੱਕ: ਹਥਿਆਰਾਂ ਦੀ ਦੌੜ (the arms race)
JA3 ਪਹਿਲਾ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਅਪਣਾਇਆ ਗਿਆ TLS ਫਿੰਗਰਪ੍ਰਿੰਟ ਸੀ। Chrome ਹੁਣ ਹਰ ਲਾਂਚ 'ਤੇ ਆਪਣੀਆਂ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੇ ਕ੍ਰਮ ਨੂੰ ਰੈਂਡਮਾਈਜ਼ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅਸਲੀ ਬ੍ਰਾਊਜ਼ਰ ਲਈ JA3 ਹੈਸ਼ ਅਸਥਿਰ ਹੋ ਜਾਂਦਾ ਹੈ। JA4 ਇਸ ਨੂੰ ਹੈਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਐਕਸਟੈਂਸ਼ਨ ਸੂਚੀ ਨੂੰ ਸੈੱਲ ਕਰਕੇ (sorting) ਹੱਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਦੋਂ ਵੀ ਇੱਕ ਸਥਿਰ ਪਛਾਣਕਰਤਾ ਮਿਲਦਾ ਹੈ ਜਦੋਂ Chrome ਕ੍ਰਮ ਨੂੰ ਬਦਲਦਾ ਹੈ। JA4 ਨੂੰ ਅਪਣਾਉਣ ਵਾਲੇ ਡਿਟੈਕਸ਼ਨ ਟੂਲ ਅਸਲੀ Chrome ਇੰਸਟੈਂਸਾਂ ਨੂੰ ਉਹਨਾਂ ਸਕ੍ਰਿਪਟਡ ਕਲਾਇੰਟਾਂ ਤੋਂ ਭਰੋਸੇਮੰਦ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਸਟੈਟਿਕ JA3 ਹੈਸ਼ ਦੀ ਕਾਪੀ ਕਰਦੇ ਹਨ।
ਡਿਵੈਲਪਰ ਅੱਜ ਕੀ ਕਰ ਸਕਦੇ ਹਨ
ਅਜਿਹਾ ਕੋਈ "ਜਾਦੂਈ ਸਟ੍ਰਿੰਗ" ਨਹੀਂ ਹੈ ਜੋ ਸਰਵਰ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਧੋਖਾ ਦੇ ਸਕੇ। ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਬੇਨਤੀ ਦੀ ਹਰ ਲੇਅਰ ਇੱਕੋ ਜਿਹੀ ਕਹਾਣੀ ਸੁਣਾਵੇ:
- User-Agent, TLS ਹੈਂਡਸ਼ੇਕ, HTTP/2 ਸੈਟਿੰਗਾਂ, ਅਤੇ ਹੈਡਰ ਦੇ ਕ੍ਰਮ ਨੂੰ ਉਸੇ ਬ੍ਰਾਊਜ਼ਰ ਵਰਜ਼ਨ ਅਤੇ OS ਦੇ ਅਨੁਸਾਰ ਰੱਖੋ।
- ਇੱਕ ਪੂਰੇ ਬ੍ਰਾਊਜ਼ਰ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਨੂੰ ਵੱਖਰੇ HTTP ਕਲਾਇੰਟ ਨਾਲ ਮਿਲਾਉਣਾ ਬੰਦ ਕਰੋ। ਜੇਕਰ ਗਤੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ Playwright ਨੂੰ ਸਾਰੀਆਂ ਨੈੱਟਵਰਕ ਕਾਲਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦਿਓ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਮਾਮੂਲੀ ਕਾਲਾਂ ਨੂੰ ਵੀ।
- ਅਜਿਹੀਆਂ ਪ੍ਰੌਕਸੀਆਂ ਚੁਣੋ ਜੋ ਕਨੈਕਸ਼ਨ ਨੂੰ ਖਤਮ ਕੀਤੇ ਬਿਨਾਂ TLS ਨੂੰ ਅੱਗੇ ਭੇਜਦੀਆਂ (pass through) ਹਨ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਅਸਲੀ TLS ਹੈਂਡਸ਼
ਜੇਕਰ ਤੁਹਾਡਾ Playwright scraper ਕੋਈ ਵੀ ਪੇਜ ਲੋਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰਿਜੈਕਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮੁੱਖ ਕਾਰਨ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ TLS fingerprint ਵਿੱਚ ਮਿਸਮੈਚ ਹੋਣਾ ਹੈ। ਇਸਦਾ ਹੱਲ ਕੋਈ ਜਲਦੀ ਵਾਲਾ ਪੈਚ ਨਹੀਂ ਹੈ; ਇਸ ਲਈ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਲੇਅਰ ਨੂੰ ਘੋਸ਼ਿਤ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਦੇ ਅਨੁਸਾਰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਅਲਾਈਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। User-Agent, TLS handshake, HTTP/2 settings, header order ਅਤੇ proxy behavior ਵਿੱਚ ਇਕਸਾਰਤਾ ਰੱਖਣਾ ਹੀ ਆਧੁਨਿਕ anti-scraping defenses ਤੋਂ ਬਚਣ ਦਾ ਇੱਕੋ ਇੱਕ ਭਰੋਸੇਮੰਦ ਤਰੀਕਾ ਹੈ।