ਤੁਸੀਂ ਨਵਾਂ ਬਿਲਡ ਜਾਰੀ ਕੀਤਾ, VPN ’ਤੇ ਗਏ, ਅਤੇ ਉਹੀ ਸਕ੍ਰੀਨ ਲੋਡ ਹੋਣਾ ਬੰਦ ਹੋ ਗਈ। Android 9 ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਵਧੇਰੇ ਆਮ ਵਿਆਖਿਆ ਵਧੇਰੇ ਨੀਰਸ ਹੈ: ਪਲੇਟਫਾਰਮ API 28 ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀਆਂ ਐਪਾਂ ਲਈ ਸਧਾਰਨ HTTP ਨੂੰ ਇਨਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ VPN ਨੇ ਸਿਰਫ਼ ਇੰਨਾ ਸੰਦਰਭ ਬਦਲਿਆ ਕਿ ਇਹ ਸਾਹਮਣੇ ਆ ਜਾਵੇ। ਤੁਸੀਂ ਜੋ ਗਲਤੀ ਦੇਖਦੇ ਹੋ ਉਹ HTTP ਕਲਾਇੰਟ ’ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਇੰਨੀ ਘੱਟ ਵਾਰ cleartext ਕਹਿੰਦੀ ਹੈ।

ਇਹ ਫੇਲ ਹੋਣਾ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

Android 9 ਤੋਂ ਪਲੇਟਫਾਰਮ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ cleartext ਬਲਾਕ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਹੀ ਐਪ API ਪੱਧਰ 28 ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ। ਸਧਾਰਨ HTTP ਪਤੇ ’ਤੇ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਵੀ ਪੈਕੇਟ ਡਿਵਾਈਸ ਤੋਂ ਨਿਕਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪਲੇਟਫਾਰਮ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਕਿਹੜੀ ਗਲਤੀ ਦੇਖਦੇ ਹੋ ਇਹ HTTP ਲਾਇਬ੍ਰੇਰੀ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਕਦੇ ਆਮ ਨੈੱਟਵਰਕ ਫੇਲ, ਕਦੇ ਸਮਾਂ ਖਤਮ, ਕਦੇ ਅਜਿਹਾ ਸੁਨੇਹਾ ਜੋ cleartext ਨੂੰ ਸਿੱਧਾ ਨਾਮ ਦਿੰਦਾ ਹੈ। ਜੋ ਇਹ ਕਦੇ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਤੁਹਾਡੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣਾ। Android ਡਿਫਾਲਟ ਅਤੇ ਡੋਮੇਨ-ਸੀਮਿਤ ਵਿਕਲਪ ਨੂੰ ਆਪਣੀ ਸੁਰੱਖਿਆ ਕਾਨਫਿਗਰੇਸ਼ਨ ਗਾਈਡ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ।

ਉਸੇ ਡਿਵਾਈਸ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਅਜੇ ਵੀ ਪੰਨਾ ਲੋਡ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਸੁਰਾਗ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਖੁੰਝਾਉਂਦੇ ਹਨ। ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਡੀ ਐਪ ਦੀ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਨੀਤੀ ਦੇ ਅਧੀਨ ਨਹੀਂ ਹਨ।

VPN ’ਤੇ ਦੋਸ਼ ਕਿਉਂ ਆਉਂਦਾ ਹੈ

ਆਮ ਤੌਰ ’ਤੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਇਕੱਠੀਆਂ ਬਦਲਦੀਆਂ ਹਨ। VPN ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਐਪ ਕੋਈ ਹੋਰ ਹੋਸਟਨਾਮ ਰਿਜ਼ਾਲਵ ਕਰ ਸਕਦੀ ਹੈ, ਡਿਵਾਈਸ ਨਵੀਂ ਅਤੇ ਨਵੇਂ ਬਿਲਡ ਵਾਲੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਬਿਲਡ ਖੁਦ ਉਸ ਨਿਸ਼ਾਨਾ API ਪੱਧਰ ’ਤੇ ਚਲਾ ਗਿਆ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਡਿਫਾਲਟ ਸਕ੍ਰਿਯ ਕਰਦਾ ਹੈ। VPN ਦਿਸਦਾ ਹੈ ਅਤੇ ਨਿਸ਼ਾਨਾ SDK ਨਹੀਂ, ਇਸ ਲਈ ਟਿਕਟ VPN ਨੂੰ ਮਿਲਦੀ ਹੈ।

ਨੈੱਟਵਰਕ ਕਾਨਫਿਗ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਬਿਲਡ ਦੇ ਨਿਸ਼ਾਨਾ ਪੱਧਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। 27 ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀ ਐਪ ਛੋਟ ਪ੍ਰਾਪਤ ਹੈ, ਅਤੇ ਇਹੀ «ਮੇਰੇ ਪੁਰਾਣੇ ਫੋਨ ’ਤੇ ਚੱਲਦਾ ਹੈ» ਵਰਗੀ ਹਰ ਰਿਪੋਰਟ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

Expo ਫਲੈਗ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਪੈਂਦਾ ਹੈ

ਪ੍ਰਬੰਧਿਤ Expo ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ app.json ਵਿੱਚ ਸੈਟਿੰਗ ਜੋੜਨਾ Android ਮੈਨੀਫੈਸਟ ਨੂੰ ਸੰਪਾਦਿਤ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਮੈਨੀਫੈਸਟ prebuild ਅਤੇ ਡਿਵੈਲਪਮੈਂਟ ਬਿਲਡ ਬਣਾਉਂਦੇ ਹਨ। ਉਸ ਪੜਾਅ ’ਤੇ ਸੈਟਿੰਗ ਕਾਨਫਿਗ ਪਲੱਗਇਨ ਲਿਖਦਾ ਹੈ। ਸਮਰਥਿਤ ਰਾਹ expo-build-properties ਹੈ, ਜੋ ਐਪ ਕਾਨਫਿਗ ਵਿੱਚ android ਹੇਠ cleartext ਵਿਕਲਪ ਨਾਲ ਕਾਨਫਿਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

{
  "plugins": [
    ["expo-build-properties", {
      "android": { "usesCleartextTraffic": true }
    }]
  ]
}

ਸਨਿੱਪਟ ਸਿਰਫ਼ ਪਲੱਗਇਨ ਵਿਕਲਪ ਸੈਟ ਕਰਦਾ ਹੈ; ਮੈਨੀਫੈਸਟ ਬਾਅਦ ਵਿੱਚ ਬਣਦਾ ਹੈ। prebuild ਜਾਂ ਨਵਾਂ ਡਿਵੈਲਪਮੈਂਟ-ਕਲਾਇੰਟ ਬਿਲਡ ਚਲਾਓ, ਫਿਰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਣੇ AndroidManifest.xml ਵਿੱਚ android:usesCleartextTraffic ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਸਿਰਫ਼ JS ਰੀਲੋਡ ਪੁਰਾਣਾ ਮੈਨੀਫੈਸਟ ਰੱਖਦਾ ਹੈ। ਪਲੱਗਇਨ ਵਰਜਨ ਨੂੰ ਉਸ Expo SDK ਨਾਲ ਮਿਲਾਓ ਜਿਸ ’ਤੇ ਪ੍ਰੋਜੈਕਟ ਚੱਲਦਾ ਹੈ। ਪਲੱਗਇਨ ਵਿਕਲਪ ਰਿਲੀਜ਼ਾਂ ਵਿਚਕਾਰ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਕਿਸੇ ਹੋਰ SDK ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਸਨਿੱਪਟ ਚੁੱਪ ਨਿਸ਼ਕਿਰਿਆਤਾ ਦਾ ਭਰੋਸੇਯੋਗ ਸਰੋਤ ਹੈ।

Bare ਵਰਕਫਲੋ ਅਤੇ ਹੋਰ ਤੰਗ ਵਿਕਲਪ

bare React Native ਲਈ ਬਰਾਬਰ ਹੈ application ਐਲੀਮੈਂਟ ’ਤੇ android:usesCleartextTraffic, ਜਾਂ ਅਜਿਹਾ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਕਾਨਫਿਗ ਜੋ ਸਿਰਫ਼ ਨਾਮਿਤ ਡੋਮੇਨਾਂ ਲਈ cleartext ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਡੋਮੇਨ-ਸੀਮਿਤ ਰੂਪ ਹੀ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅੰਦਰੂਨੀ API ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ HTTPS ’ਤੇ ਰੱਖਦਾ ਹੈ। ਇਹ ਆਪਣੀ ਛੋਟ ਸੂਚੀ ਵੀ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਮੀਖਿਅਕ ਠੀਕ ਉਸੇ ਹਿੱਸੇ ਬਾਰੇ ਪੁੱਛੇਗਾ।

ਦੋਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪਹੁੰਚ ਤੁਹਾਡੇ ਵੱਲੋਂ ਨਾਮ ਨਾ ਦਿੱਤੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਪਲੇਟਫਾਰਮ ਦਾ ਡਿਫਾਲਟ ਨਹੀਂ ਬਦਲਦੀ।

ਪਹਿਲਾਂ ਡਿਵਾਈਸ ਲੌਗ ਤੋਂ ਸਾਬਤ ਕਰੋ

ਕਾਨਫਿਗ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਫੇਲ ਹੋਣਾ ਲਵੋ। ਜੁੜੇ ਡਿਵਾਈਸ ’ਤੇ adb logcat ਪਲੇਟਫਾਰਮ ਦਾ cleartext ਇਨਕਾਰ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸ ਕੰਪੋਨੈਂਟ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਜਿਸਨੇ ਇਹ ਪੈਦਾ ਕੀਤਾ। ਰੱਦ ਕੀਤਾ ਸਾਕਟ, ਰਿਜ਼ਾਲਵ ਨਾ ਹੋਣ ਵਾਲਾ ਨਾਮ ਜਾਂ ਫੇਲ TLS ਹੈਂਡਸ਼ੇਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਤੇ ਹੋਰ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ cleartext ਸਕ੍ਰਿਯ ਕਰਨਾ ਐਪ ਨੂੰ ਬੇਕਾਰ ਕਮਜ਼ੋਰ ਹੀ ਕਰੇਗਾ।

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

ਐਂਡਪੁਆਇੰਟ HTTPS ’ਤੇ ਜਵਾਬ ਦੇਣਾ ਸ਼ੁਰੂ ਕਰੇ ਤਾਂ ਇਜਾਜ਼ਤ ਹਟਾਓ, ਦੁਬਾਰਾ ਬਿਲਡ ਕਰੋ ਅਤੇ ਉਸੇ ਸੈਸ਼ਨ ਵਿੱਚ VPN ’ਤੇ ਅਤੇ ਆਮ Wi-Fi ’ਤੇ ਟੈਸਟ ਕਰੋ। ਨਾਮ ਰਿਜ਼ਾਲਿਊਸ਼ਨ ਇਹਨਾਂ ਦੋ ਰਾਹਾਂ ਵਿੱਚ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਸੱਚ ਬੋਲ ਰਿਹਾ ਹੈ ਇਹ ਸਿਰਫ਼ ਉਹ ਜੋੜੀ ਹੀ ਦੱਸਦੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ