VPN ਰਾਹੀਂ iPhone ਐਪ ਤੋਂ ਅੰਦਰੂਨੀ API ਕਿਵੇਂ ਕਾਲ ਕਰੀਏ

API ਉਸੇ ਫ਼ੋਨ ਦੇ Safari ਵਿੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਪਰ ਐਪ ਦੀ ਬੇਨਤੀ ਸਮਾਂ ਸੀਮਾ ਲੰਘ ਜਾਂਦੀ ਹੈ। ਇਹ ਅੰਤਰ ਆਮ ਤੌਰ 'ਤੇ ਟਨਲ ਨਹੀਂ ਹੁੰਦਾ: ਅੰਦਰੂਨੀ ਸੇਵਾ ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੀ ਐਪ ਆਮ HTTPS ਬੇਨਤੀ ਕਰਦੀ ਹੈ, ਅਤੇ ਡਿਵਾਈਸ 'ਤੇ ਮੌਜੂਦ VPN ਸਿਰਫ਼ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਬੇਨਤੀ ਦਾ ਕੋਈ ਰਾਹ ਹੈ ਜਾਂ ਨਹੀਂ। ਐਪ ਵਿੱਚ ਦੂਜੀ ਟਨਲ ਲਿਖਣਾ ਇੱਕ ਉਤਪਾਦ ਫੈਸਲਾ ਹੈ, ਸਮਾਂ ਸੀਮਾ ਲਈ ਮੁਰੰਮਤ ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤਾ ਭਾਗ ਫੇਲ੍ਹਤਾ ਨੂੰ ਇਸ ਆਧਾਰ 'ਤੇ ਵਰਗੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿੱਥੇ ਹੁੰਦੀ ਹੈ, ਐਪ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਤਰੁੱਟੀ-ਸਤ੍ਹ ਨੂੰ ਵਰਤਦਿਆਂ।

ਟਨਲ ਤੋਂ ਨਹੀਂ, ਤਰੁੱਟੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

ਕੰਮ ਮੈਟ੍ਰਿਕਸ ਅਗਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਕਿ ਕਦੇ ਕੋਈ ਕਨੈਕਸ਼ਨ ਬਣਿਆ ਜਾਂ ਨਹੀਂ, ਜੋ ਬਿਨਾਂ ਰਾਹ ਵਾਲੀ ਬੇਨਤੀ ਨੂੰ ਸਰਵਰ ਵੱਲੋਂ ਬਹੁਤ ਦੇਰ ਨਾਲ ਜਵਾਬ ਦਿੱਤੀ ਬੇਨਤੀ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਲਈ ਵੀ ਟਨਲ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ; ਬੇਨਤੀ ਦੇ ਆਪਣੇ ਨਿਦਾਨ ਨੂੰ ਤੁਸੀਂ ਪੜ੍ਹ ਸਕੋ ਅਜਿਹੀ ਥਾਂ ਛਾਪਣ ਦੀ ਲੋੜ ਹੈ।

ਨਾਮ-ਹੱਲ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ

ਜਿਵੇਂ ਕਿ api.corp.example ਵਰਗਾ ਛੋਟਾ ਦਫ਼ਤਰੀ ਨਾਮ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਖੋਜ ਡੋਮੇਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਫ਼ੋਨ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਐਪ ਉਹ ਨਾਮ ਹੱਲ ਕਰਦੀ ਹੈ ਜੋ ਸਿਰਫ਼ ਇਮਾਰਤ ਦੇ ਅੰਦਰ ਮੌਜੂਦ ਹੈ। NSURLErrorCannotFindHost ਇਸਦਾ ਦਸਤਖ਼ਤ ਹੈ। ਪੂਰਾ ਹੋਸਟਨਾਮ VPN ਜੋ ਵੀ ਰਿਜ਼ੋਲਵਰ ਸਥਾਪਿਤ ਕਰੇ, ਉਸ ਰਾਹੀਂ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਖੋਜ ਡੋਮੇਨ ਦੀ ਗਾਰੰਟੀ ਨਾ ਹੋਵੇ ਤਾਂ ਐਪ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਰੂਪ ਮੰਗਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਾਮ ਨੂੰ ਪਤੇ ਨਾਲ ਬਦਲਣਾ ਅਤੇ ਪ੍ਰਮਾਣਪੱਤਰ ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਫੇਲ੍ਹਤਾ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਹਿਲਾਉਂਦਾ ਹੈ।

ਨਿੱਜੀ DNS ਰਿਕਾਰਡ ਅਤੇ ਠੀਕ ਉਸੇ ਨਾਮ ਲਈ ਜਾਰੀ ਪ੍ਰਮਾਣਪੱਤਰ ਸਮਰਥਿਤ ਜੋੜੀ ਹਨ। ਬਾਕੀ ਸਭ ਕੁਝ ਇੱਕ ਅਜਿਹਾ ਉਪਾਅ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰਾਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।

ਸਮਾਂ ਸੀਮਾ ਨਾਮ ਦਾ ਨਹੀਂ, ਰਾਹ ਦਾ ਸਵਾਲ ਹੈ

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

ਬ੍ਰਾਊਜ਼ਰ ਤੁਲਨਾ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਡਿਵਾਈਸ ਦੀ ਕਿਸੇ ਐਪ ਕੋਲ ਰਾਹ ਹੈ. ਇਹ ਕਦੇ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਤੁਹਾਡੇ ਬਿਲਡ ਕੋਲ ਹੈ, ਇਸ ਲਈ ਦੋਵੇਂ ਟੈਸਟ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕਰਨੇ ਪੈਂਦੇ ਹਨ।

ਭਰੋਸਾ ਫੇਲ੍ਹਤਾਵਾਂ ਪ੍ਰਮਾਣਪੱਤਰ 'ਤੇ ਨਾਮ ਬਾਰੇ ਹਨ

NSURLErrorServerCertificateUntrusted ਇਸਦੇ ਹੇਠਲੀ TLS ਤਰੁੱਟੀ ਨਾਲ ਮਿਲ ਕੇ ਭਾਵ ਲੜੀ ਜਾਂ ਪਛਾਣ ਜਾਂਚ ਫੇਲ੍ਹ ਹੋਈ। ਅੰਦਰੂਨੀ CA ਡਿਵਾਈਸ 'ਤੇ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਹੋਰ ਹੋਸਟਨਾਮ ਲਈ ਜਾਰੀ ਪ੍ਰਮਾਣਪੱਤਰ ਕਿੰਨੀ ਵੀ ਨੈੱਟਵਰਕ ਮੁੜ-ਸੰਰਚਨਾ ਤੋਂ ਬਾਅਦ ਵੀ ਗਲਤ ਹੀ ਰਹਿੰਦਾ ਹੈ। Apple ਦੀ App Transport Security ਮਾਰਗਦਰਸ਼ਨ ਇਹਨਾਂ URL ਲੋਡ ਕਰਨ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ, ਅਤੇ ਸਾਧਾਰਨ HTTP ਸੇਵਾ ਦੁਆਲੇ ਟਨਲ ਉਸ ਸੇਵਾ ਨੂੰ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਬਣਾਉਂਦੀ।

ਪਛਾਣ ਜਾਂ ਭਰੋਸਾ-ਐਂਕਰ ਠੀਕ ਕਰੋ ਅਤੇ ਅਪਵਾਦ ਸੂਚੀ ਖਾਲੀ ਰੱਖੋ। ਮਨਮਾਨੀ ਲੋਡ ਲਈ ਵਿਆਪਕ ਅਪਵਾਦ ਵਿਕਾਸ ਦੌਰਾਨ ਫੇਲ੍ਹਤਾ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਰ ਵਰਤੋਂਕਾਰ ਲਈ ਉਹਨੂੰ ਥਾਂ 'ਤੇ ਹੀ ਛੱਡ ਦਿੰਦਾ ਹੈ।

HTTP ਅਸਵੀਕਾਰ ਐਪ ਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਦਾ ਨਹੀਂ

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

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

ਹਰ ਕਤਾਰ ਨੂੰ ਉਸਦੇ ਹੇਠਲੀ ਕਤਾਰ ਨਾਲੋਂ ਸਸਤੇ ਵਿੱਚ ਪਰਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਉਸੇ ਬੇਨਤੀ ਦੀ ਵੱਖਰੀ ਪਰਤ ਨੂੰ ਬਾਹਰ ਕਰਦੀ ਹੈ। ਕਤਾਰ ਮੇਲ ਖਾਣ ਤੱਕ ਟੇਬਲ ਵਿੱਚ ਹੇਠਾਂ ਜਾਓ, ਫਿਰ ਨੈੱਟਵਰਕ ਬਦਲਣਾ ਬੰਦ ਕਰੋ।