Android VPN 'ਤੇ Keystore ਗਲਤੀ: ਦੁਬਾਰਾ ਰਜਿਸਟਰ, ਅਨਲੌਕ ਜਾਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼?
Android keystore ਦੇ ਤਿੰਨ ਨਤੀਜਿਆਂ ਲਈ ਤਿੰਨ ਵੱਖਰੀਆਂ ਰਿਕਵਰੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਐਪ ਦੀ ਸਟੋਰੇਜ ਸਾਫ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਨਲੌਕ, ਦੁਬਾਰਾ ਰਜਿਸਟਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰਦਾਤਾ ਦੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਪ੍ਰੋਫਾਈਲ ਅਜੇ ਵੀ ਸੂਚੀ ਵਿੱਚ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੀ ਸਥਾਪਿਤ ਦਿਖਦਾ ਹੈ, ਅਤੇ ਕਨੈਕਟ ਬਟਨ ਸਿਰਫ਼ «Keystore ਗਲਤੀ» ਕਹਿਣ ਵਾਲੇ ਸੁਨੇਹੇ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਐਪ ਦੀ ਸਟੋਰੇਜ ਸਾਫ਼ ਕਰਨ ਜਾਂ ਫ਼ੋਨ ਸੌਂਪਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਕੁੰਜੀ ਓਪਰੇਸ਼ਨ ਅਸਫਲ ਹੋਇਆ। ਤਿੰਨ ਨਤੀਜੇ ਇੱਕੋ ਸੰਵਾਦ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਕਾਰਵਾਈਆਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ — ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਤਬਾਹਕਾਰੀ ਹੈ। ਇਹ ਤੁਲਨਾ ਦਸ ਮਿੰਟ ਦੀ ਲਾਇਕ ਹੈ, ਕਿਉਂਕਿ ਗਲਤ ਸ਼ਾਖਾ ਤੁਹਾਨੂੰ ਉਹ ਪਛਾਣ ਗੁਆ ਦਿੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ।
ਇੱਕ ਸੰਵਾਦ ਪਿੱਛੇ ਤਿੰਨ ਅਸਫਲਤਾਵਾਂ
ਪਹਿਲੀ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ। ਕੁੰਜੀ ਮੌਜੂਦ ਹੈ ਅਤੇ ਵੈਧ ਹੈ, ਪਰ ਇਸਦੀ ਵਰਤੋਂ ਲਈ ਵਰਤੋਂਕਾਰ ਨੂੰ ਹਾਜ਼ਰੀ ਸਾਬਤ ਕਰਨੀ ਪੈਂਦੀ ਹੈ — ਡਿਵਾਈਸ ਅਨਲੌਕ, ਬਾਇਓਮੈਟ੍ਰਿਕ ਜਾਂ ਕੰਮ-ਪ੍ਰੋਫਾਈਲ ਚੁਣੌਤੀ। ਜੇ ਲਾਕ ਸਮਾਂ-ਸੀਮਾ, ਰਜਿਸਟਰਡ ਬਾਇਓਮੈਟ੍ਰਿਕ ਜਾਂ ਪ੍ਰੋਫਾਈਲ ਦੀ ਸਥਿਤੀ ਹਾਲ ਹੀ ਵਿੱਚ ਬਦਲੀ ਹੈ, ਤਾਂ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਕੁੰਜੀ ਆਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਠੀਕ ਹੈ।
ਦੂਜੀ ਸਥਾਈ ਅਵੈਧਤਾ ਹੈ। ਕੁਝ ਕੁੰਜੀ ਸਮੱਗਰੀ ਨੂੰ ਪਲੇਟਫਾਰਮ ਨੀਤੀ ਦੁਆਰਾ ਅਵੈਧ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਲਾਕ ਢੰਗ ਰੀਸੈਟ ਹੁੰਦਾ ਹੈ ਜਾਂ ਬਾਇਓਮੈਟ੍ਰਿਕ ਰਜਿਸਟਰੇਸ਼ਨ ਬਦਲਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਸਨੂੰ ਬਚਾਉਣ ਵਾਲਾ ਬੰਧਨ ਹੁਣ ਲਾਗੂ ਨਹੀਂ ਰਹਿੰਦਾ। ਕੁੰਜੀ ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਰਿਕਵਰੀ ਯੋਜਨਾ ਨਹੀਂ ਹੈ; ਪਛਾਣ ਨੂੰ ਉਸ ਰਜਿਸਟਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਬਦਲਣਾ ਪਵੇਗਾ ਜਿਸਨੇ ਇਹ ਜਾਰੀ ਕੀਤੀ ਸੀ।
ਤੀਜੀ ਪ੍ਰਦਾਤਾ ਦੀ ਅਸਫਲਤਾ ਹੈ: keystore ਸੇਵਾ ਹੁਣ ਓਪਰੇਸ਼ਨ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕੀ। ਇਹ ਉਹ ਸ਼੍ਰੇਣੀ ਹੈ ਜਿਸਨੂੰ ਕਦੇ-ਕਦੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਲਾਇਕ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕੋ।
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
ਧਿਆਨ ਦਿਓ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਦੋ ਤਬਾਹਕਾਰੀ ਨਹੀਂ ਹਨ ਅਤੇ ਇੱਕ ਦਾ ਡਿਵਾਈਸ ਪੱਧਰ 'ਤੇ ਕੋਈ ਹੱਲ ਨਹੀਂ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਫ਼ੋਨ ਮਿਟਾਉਣ ਨਾਲ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਜੋ ਕਿ ਲੋਕ ਪਹਿਲਾ ਕਦਮ ਚੁੱਕਦੇ ਹਨ ਕਿਉਂਕਿ ਸੰਵਾਦ ਉਨ੍ਹਾਂ ਨੂੰ ਹੋਰ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ।
ਦੁਬਾਰਾ ਰਜਿਸਟਰੇਸ਼ਨ ਬਨਾਮ ਡੇਟਾ ਸਫ਼ਾਈ
ਇਹ ਦੋਵੇਂ ਬਾਹਰੋਂ ਸਮਾਨ ਦਿਖਦੇ ਹਨ ਅਤੇ ਨਹੀਂ ਹਨ। ਦੁਬਾਰਾ ਰਜਿਸਟਰੇਸ਼ਨ ਜਾਰੀ ਕਰਨ ਵਾਲੇ ਸਿਸਟਮ ਤੋਂ ਨਵੀਂ ਪਛਾਣ ਮੰਗਦੀ ਹੈ — ਇਸ ਡਿਵਾਈਸ ਨਾਲ ਬੱਝਿਆ ਨਵਾਂ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਕੁੰਜੀ — ਅਤੇ ਪੁਰਾਣੀ ਨੂੰ ਰਿਟਾਇਰ ਕਰਦੀ ਹੈ। ਡੇਟਾ ਸਫ਼ਾਈ ਐਪ ਦੀ ਸੰਭਾਲੀ ਸਥਿਤੀ ਮਿਟਾ ਦਿੰਦੀ ਹੈ, ਜੋ ਕੁੰਜੀ ਹਟਾਏ ਬਿਨਾਂ ਕੁੰਜੀ ਦਾ ਹਵਾਲਾ ਹਟਾ ਸਕਦੀ ਹੈ, ਜਾਂ ਕੁੰਜੀ ਹਟਾ ਕੇ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦਾ ਅਧਿਕਾਰ ਛੱਡੇ ਬਿਨਾਂ ਛੱਡ ਸਕਦੀ ਹੈ।
ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਨਿਰਯਾਤ ਨਾ ਹੋਣ ਯੋਗ ਕੁੰਜੀਆਂ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਹੀ ਸਥਾਨਾਂਤਰਿਤ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਡਿਵਾਈਸ ਦੇ keystore ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਉਪਲਬਧ ਹਾਰਡਵੇਅਰ ਜਾਂ ਪ੍ਰਦਾਤਾ ਦੇ ਸਹਾਰੇ, ਅਤੇ ਉਹ ਉਹ ਚੀਜ਼ ਨਹੀਂ ਹਨ ਜੋ ਬੈਕਅਪ ਫੜਦਾ ਹੈ ਅਤੇ ਰੀਸਟੋਰ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ। ਜੇ ਤੈਨਾਤੀ ਦੀ ਪਛਾਣ ਨਿਰਯਾਤ ਨਾ ਹੋਣ ਯੋਗ ਕੁੰਜੀ ਹੈ, ਤਾਂ ਰਿਕਵਰੀ ਵਜੋਂ ਦੁਬਾਰਾ ਰਜਿਸਟਰੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਰਜਿਸਟਰੇਸ਼ਨ ਲੈਣ ਲਈ ਤੁਹਾਡੇ ਕੋਲ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਾਹ ਹੈ — ਕੁਝ ਸੰਸਥਾਵਾਂ ਇਸ ਲਈ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਮੰਗਦੀਆਂ ਹਨ, ਜੋ ਠੀਕ ਉਹੀ ਸੀ ਜੋ ਖਰਾਬ VPN ਦੇ ਰਿਹਾ ਸੀ।
ਇਸ ਲਈ ਕ੍ਰਮ ਇਹ ਹੈ: ਸਮਰਥਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਰਾਹ ਅਜ਼ਮਾਓ, ਫਿਰ ਪਤਾ ਕਰੋ ਕਿ ਕੁੰਜੀ ਸਥਾਈ ਤੌਰ 'ਤੇ ਅਵੈਧ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਸਿਰਫ਼ ਤਾਂ ਹੀ ਪਛਾਣ ਬਦਲੋ। ਸਟੋਰੇਜ ਸਾਫ਼ ਕਰਨਾ ਸਭ ਤੋਂ ਅੰਤ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਇਹ ਜਾਣਨ ਤੋਂ ਬਾਅਦ ਕਿ ਕੀ ਦੁਬਾਰਾ ਬਣੇਗਾ, ਪਹਿਲਾਂ ਨਹੀਂ ਕਿਉਂਕਿ ਇਹ ਸੌਖਾ ਹੈ।
ਸਿਰਫ਼ ਉਹੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਯੋਗ ਹੈ
ਪੁਰਾਣੇ ਪਲੇਟਫਾਰਮ ਸੰਸਕਰਣ keystore ਗਲਤੀਆਂ ਨੂੰ ਇੱਕ ਹੀ ਆਪਵਾਦ ਵਿੱਚ ਇਕੱਠਾ ਕਰਦੇ ਸਨ, ਇਸ ਲਈ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। API 33 ਤੋਂ ਆਪਵਾਦ ਕਿਸਮ ਢਾਂਚਾ ਰੱਖਦੀ ਹੈ: ਸੰਖਿਆਤਮਕ ਗਲਤੀ, ਅਸਥਾਈ ਅਸਫਲਤਾ ਦਾ ਝੰਡਾ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨੀਤੀ। ਕਲਾਇੰਟ ਡਿਵੈਲਪਰ ਲਈ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨੀਤੀ ਤਦ ਹੀ ਅਰਥ ਰੱਖਦੀ ਹੈ ਜਦੋਂ ਅਸਥਾਈਤਾ ਦਾ ਝੰਡਾ ਸੱਚ ਹੋਵੇ; ਸਥਾਈ ਅਵੈਧਤਾ ਦਾ ਕੋਈ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਸਮਾਂ-ਸਾਰਣੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਲੂਪ ਵਿੱਚ ਇਸਨੂੰ ਕੁੱਟਣਾ ਸਿਰਫ਼ ਬੈਟਰੀ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਲੌਗ ਭਰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਲਾਇੰਟ ਲਿਖਣ ਦੀ ਬਜਾਏ ਨਿਦਾਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਵਿਹਾਰਕ ਨਤੀਜਾ ਉਹੀ ਹੈ। ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਸਮਾਨ ਅਸਫਲਤਾਵਾਂ ਇੱਕ ਵਾਰੀ ਦੀ ਖ਼ਰਾਬੀ ਨੂੰ ਬਾਹਰ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਸਥਾਈ ਤੌਰ 'ਤੇ ਅਵੈਧ ਕੁੰਜੀ ਨੂੰ ਕੁਝ ਸਮੇਂ ਤੋਂ ਅਣਉਪਲਬਧ ਪ੍ਰਦਾਤਾ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕਰਦੀਆਂ — ਪ੍ਰਦਾਤਾ ਦੀ ਰੁਕਾਵਟ ਦਸਵੀਂ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਵੀ ਪਹਿਲੀ ਵਾਂਗ ਹੀ ਦਿਖਦੀ ਹੈ। API 33 ਦੇ ਢਾਂਚਾਗਤ ਖੇਤਰਾਂ ਤੋਂ ਬਿਨਾਂ, ਦੁਹਰਾਓ ਨੂੰ ਦੂਜੇ ਸੰਕੇਤ ਦੀ ਭਾਲ ਦਾ ਕਾਰਨ ਮੰਨੋ — ਗਲਤੀ ਕੋਡ ਜੇ ਤੁਹਾਡਾ ਬਿਲਡ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ, ਆਪਰੇਟਰ ਦੀ ਸਥਿਤੀ, ਜਾਂ ਉਸੇ ਡਿਵਾਈਸ 'ਤੇ ਦੂਜੀ ਕੁੰਜੀ ਦਾ ਸਫਲ ਹੋਣਾ — ਕੁੰਜੀ ਮਰੀ ਹੋਣ ਦੇ ਸਬੂਤ ਵਜੋਂ ਨਹੀਂ।
ਕਾਰਨ-ਜ਼ੰਜੀਰ ਪੜ੍ਹੋ, ਲੇਬਲ ਨਹੀਂ
ਐਪਲੀਕੇਸ਼ਨ ਮੂਲ ਆਪਵਾਦ ਨੂੰ ਲਪੇਟਦੇ ਹਨ, ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਦਾ ਦੋਸਤਾਨਾ ਟੈਕਸਟ ਅਕਸਰ ਉਹ ਇੱਕੋ ਖੇਤਰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਜੋ ਸ਼ਾਖਾ ਤੈਅ ਕਰਦਾ ਹੈ। ਕਾਰਨ-ਜ਼ੰਜੀਰ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਦਾ ਸਮਾਂ-ਛਾਪ ਸੰਭਾਲੋ: ਬਾਹਰੀ ਆਪਵਾਦ ਆਮ ਤੌਰ 'ਤੇ ਓਪਰੇਸ਼ਨ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਕਾਰਨ ਕੁੰਜੀ ਦੀ ਸਥਿਤੀ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ।
ਇਸ ਅਨੁਮਾਨ ਦਾ ਵਿਰੋਧ ਕਰੋ ਕਿ ਦੋ ਅਸਫਲ ਐਪਾਂ ਨੇ ਖਰਾਬ ਹੈਂਡਸੈੱਟ ਸਾਬਤ ਕੀਤਾ ਹੈ। ਵੱਖਰੀਆਂ ਕੁੰਜੀਆਂ ਵੱਖਰੇ ਪ੍ਰਦਾਤਿਆਂ ਅਤੇ ਸੁਰੱਖਿਆ ਪੱਧਰਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਹੀ ਐਪ ਉਹੀ ਓਪਰੇਸ਼ਨ ਬਿਲਕੁਲ ਨਹੀਂ ਕਰਦੀ ਹੋ ਸਕਦੀ ਹੈ — ਦਸਤਖ਼ਤ, ਡੀਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਕੁੰਜੀ ਪ੍ਰਮਾਣਿਕਤਾ ਇੱਕੋ ਸੇਵਾ ਲਈ ਵੱਖਰੀਆਂ ਬੇਨਤੀਆਂ ਹਨ। KeyStoreException ਹਵਾਲਾ ਨਵੇਂ API ਪੱਧਰਾਂ 'ਤੇ ਢਾਂਚਾਗਤ ਖੇਤਰਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਜਾਂਚਣ ਦੀ ਥਾਂ ਹੈ ਕਿ ਤੁਹਾਡਾ ਬਿਲਡ ਅਸਲ ਵਿੱਚ ਕੀ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ।
ਹਾਰਡਵੇਅਰ ਦੇ ਸਿੱਟੇ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੀ ਗੱਲ ਬਹੁਤਿਆਂ ਦੀ ਧਾਰਨਾ ਨਾਲੋਂ ਤੰਗ ਹੈ: ਉਹੀ ਓਪਰੇਸ਼ਨ, ਉਸੇ ਪ੍ਰਦਾਤਾ 'ਤੇ, ਸੁਤੰਤਰ ਕੁੰਜੀਆਂ ਵਿੱਚ ਕੁੰਜੀ-ਪੱਧਰੀ ਨਹੀਂ ਸਗੋਂ ਪ੍ਰਦਾਤਾ-ਪੱਧਰੀ ਗਲਤੀ ਨਾਲ ਅਸਫਲ ਹੋਣਾ। ਇਹ ਪਲੇਟਫਾਰਮ ਦੇ ਨਿਦਾਨ ਦਾ ਸਵਾਲ ਹੈ, ਡਿਵਾਈਸਾਂ ਦੇ ਬੈਚ ਬਾਰੇ ਸਹਾਇਤਾ ਫੋਰਮ ਥ੍ਰੈਡ ਦਾ ਨਹੀਂ।
ਫ਼ੈਸਲਾ ਲੈਂਦਿਆਂ ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ
Android ਬਿਲਡ, ਕਲਾਇੰਟ ਸੰਸਕਰਣ, ਚੁਣਿਆ ਪ੍ਰੋਫਾਈਲ, ਅਸਫਲ ਓਪਰੇਸ਼ਨ, ਅਤੇ ਕੀ ਹਾਲ ਹੀ ਵਿੱਚ ਕੁਝ ਬਦਲਿਆ — OS ਅੱਪਡੇਟ, ਲਾਕ-ਸਕ੍ਰੀਨ ਬਦਲਾਅ, ਨਵੀਂ ਉਂਗਲੀ ਦਾ ਨਿਸ਼ਾਨ, ਦੁਬਾਰਾ ਰਜਿਸਟਰੇਸ਼ਨ — ਦਰਜ ਕਰੋ। ਕ੍ਰਮ ਨੂੰ ਕਾਰਨ ਦੇ ਸਬੂਤ ਵਜੋਂ ਨਹੀਂ, ਸੰਦਰਭ ਵਜੋਂ ਦਰਜ ਕਰੋ; ਕੁੰਜੀ ਅਸਫਲਤਾ ਤੋਂ ਪਹਿਲਾਂ ਲਾਕ ਬਦਲਾਅ ਸੰਭਾਵਿਤ ਸਹਿ-ਸੰਬੰਧ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ।
ਫਿਰ ਤੁਸੀਂ ਤੈਅ ਕੀਤੀ ਸ਼ਾਖਾ ਅਨੁਸਾਰ ਕੰਮ ਕਰੋ। ਅਸਥਾਈ: ਪਛਾਣ ਰੱਖੋ, ਸਮਰਥਿਤ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਰਾਹ ਵਰਤੋ। ਪ੍ਰਮਾਣਿਕਤਾ ਲੋੜੀਂਦੀ: ਸਮਰਥਿਤ ਅਨਲੌਕ ਪ੍ਰਵਾਹ ਪੂਰਾ ਕਰੋ ਅਤੇ ਸੰਵਾਦ ਪਾਰ ਕਰਨ ਲਈ ਇਸਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਬਜਾਏ ਤੈਨਾਤੀ ਦੀ ਲੋੜੀਂਦੀ ਲਾਕ ਨੀਤੀ ਰੱਖੋ। ਸਥਾਈ ਤੌਰ 'ਤੇ ਅਵੈਧ: ਆਮ ਰਜਿਸਟਰੇਸ਼ਨ ਰਾਹੀਂ ਪਛਾਣ ਬਦਲੋ ਅਤੇ ਰਿਟਾਇਰ ਕਰੋ।
ਨਵੇਂ ਅਧਿਕ੍ਰਿਤ ਕਨੈਕਸ਼ਨ 'ਤੇ, ਅਸਲ ਸਰੋਤ ਵੱਲ, ਸਰਵਰ ਪ੍ਰਮਾਣਿਕਤਾ ਅਜੇ ਵੀ ਸਮਰੱਥ ਰੱਖਦਿਆਂ ਨਤੀਜਾ ਸਾਬਤ ਕਰਕੇ ਸਮਾਪਤ ਕਰੋ। ਜੋ ਸਿਰਫ਼ ਢਿੱਲੀ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸਨੇ ਕੁੰਜੀ ਦੀ ਸਮੱਸਿਆ ਠੀਕ ਨਹੀਂ ਕੀਤੀ — ਇਸਨੇ ਇਸਨੂੰ ਨੈੱਟਵਰਕ ਪਰਤ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਹੈ, ਜਿੱਥੇ ਇਹ ਬਾਅਦ ਵਿੱਚ ਵਧੇਰੇ ਮਾੜੇ ਲੱਛਣਾਂ ਨਾਲ ਸਾਹਮਣੇ ਆਵੇਗੀ।
- ਤਿੰਨ ਸ਼ਾਖਾਵਾਂ: ਪ੍ਰਮਾਣਿਕਤਾ ਲੋੜੀਂਦੀ, ਸਥਾਈ ਤੌਰ 'ਤੇ ਅਵੈਧ, ਪ੍ਰਦਾਤਾ 'ਤੇ ਅਸਥਾਈ।
- ਸਿਰਫ਼ ਤੀਜੀ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦਾ ਲਾਭ ਹੈ, ਅਤੇ ਉਹ ਵੀ ਆਪਣੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨੀਤੀ ਅਨੁਸਾਰ।
- ਬਦਲਵੀਂ ਰਜਿਸਟਰੇਸ਼ਨ ਪਹੁੰਚ ਬਹਾਲ ਕਰਦੀ ਹੈ; ਡੇਟਾ ਸਫ਼ਾਈ ਉਹ ਵਿਕਲਪ ਹਟਾ ਦਿੰਦੀ ਹੈ।
- ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਅਤੇ ਆਮ ਸਰਵਰ ਪਛਾਣ ਜਾਂਚ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ।