VPN ਰਾਹੀਂ Salesforce CLI ਲੌਗਇਨ: CLI, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ API ਹੋਸਟ

Salesforce CLI ਲੌਗਇਨ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਇੱਕ ਸਮੱਸਿਆ ਵਜੋਂ ਦਰਜ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਤਿੰਨ ਹੁੰਦੀਆਂ ਹਨ। CLI ਪ੍ਰਕਿਰਿਆ ਕਿਤੇ ਚੱਲਦੀ ਹੈ, ਵੈੱਬ ਫਲੋ ਪੂਰੀ ਕਰਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਕਿਤੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਾਲੀ API ਕਾਲ ਕਿਤੇ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਤਿੰਨ ਥਾਵਾਂ ਨੂੰ ਇੱਕੋ ਰੂਟ, ਰਿਜ਼ੋਲਵਰ ਜਾਂ ਆਗਿਆ ਸੂਚੀ ਸਾਂਝੀ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਟਨਲ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨੂੰ ਰੋਕ ਰਹੀ ਹੈ ਇਹ ਜਾਣਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। ਲੌਗਇਨ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕੌਣ ਅਸਫਲ ਹੋਇਆ।

ਤਿੰਨ ਹੋਸਟ, ਇੱਕ ਲੌਗਇਨ ਕਹਾਣੀ

ਵੈੱਬ ਲੌਗਇਨ ਫਲੋ ਪਛਾਣ ਦਾ ਕਦਮ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਹ ਬ੍ਰਾਊਜ਼ਰ ਅਕਸਰ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਉੱਤੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ CLI ਦੂਰ ਦੇ ਵਿਕਾਸ ਹੋਸਟ ਜਾਂ ਕੰਟੇਨਰ ਵਿੱਚ ਬੈਠਾ ਹੁੰਦਾ ਹੈ। ਲੈਪਟਾਪ ਕੋਲ VPN ਕਲਾਇੰਟ ਹੈ, ਦੂਰ ਦੇ ਹੋਸਟ ਕੋਲ ਪਲੇਟਫਾਰਮ ਟੀਮ ਨੇ ਜੋ ਦਿੱਤਾ ਹੈ ਉਹ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਵਿਵਸਥਾਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੂਜੀ ਨੂੰ ਆਪਣੇ ਆਪ ਨਹੀਂ ਢਕਦੀ। ਸਟੇਟਸ ਬਾਰ ਵਿੱਚ VPN ਆਈਕਨ ਅਜਿਹੇ ਹੋਸਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਜਿਸ ਨੇ ਕਦੇ ਕਲਾਇੰਟ ਨਹੀਂ ਚਲਾਇਆ।

ਲੌਗਇਨ ਤੋਂ ਬਾਅਦ CLI ਆਪਣੀਆਂ API ਬੇਨਤੀਆਂ ਪ੍ਰਕਿਰਿਆ ਜਿੱਥੇ ਰਹਿੰਦੀ ਹੈ ਉੱਥੋਂ ਕਰਦੀ ਹੈ। ਉਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ DNS, ਰੂਟਿੰਗ, TLS ਭਰੋਸਾ ਅਤੇ org ਵੱਲੋਂ ਕਲਾਇੰਟ ਅਧਿਕਾਰਤਾ ਚਾਹੀਦੀ ਹੈ, ਜੋ ਚਾਰ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਆਪਣੇ ਆਪ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। ਸੋਹਣੇ ਢੰਗ ਨਾਲ ਸਾਈਨ ਇਨ ਕੀਤਾ ਬ੍ਰਾਊਜ਼ਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਦੋਵੇਂ ਅੱਧ ਇੱਕੋ ਟਾਈਮਲਾਈਨ ਉੱਤੇ ਰੱਖੋ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਅੰਕ ਦਿਓ। ਤਦ ਇੱਕ ਟਿਕਟ ਦੱਸ ਸਕਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਅੱਧ ਟੁੱਟਾ, ਮਲਕੀਅਤ ਦੀ ਬਹਿਸ ਵਿੱਚ ਬਦਲੇ ਬਿਨਾਂ।

org ਦੀ ਐਂਟਰੀ org ਤੋਂ ਹੀ ਲਓ, ਯਾਦਦਾਸ਼ਤ ਤੋਂ ਨਹੀਂ

ਵੈੱਬ ਫਲੋ ਇੱਕ ਇੰਸਟੈਂਸ URL ਲੈਂਦੀ ਹੈ ਅਤੇ ਨਤੀਜਾ ਉਪਨਾਮ ਹੇਠ ਸੰਭਾਲਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਮੁੱਲ org ਮਾਲਕ ਤੋਂ ਆਉਣੇ ਚਾਹੀਦੇ ਹਨ, ਸਹਿਕਰਮੀ ਦੇ ਟਰਮੀਨਲ ਇਤਿਹਾਸ ਤੋਂ ਨਹੀਂ। ਪੁਰਾਣੀ ਟਿਕਟ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਸੈਂਡਬਾਕਸ ਹੋਸਟ ਗਲਤ org ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਹੋਣ ਅਤੇ ਫਿਰ ਹਰ ਕੁਏਰੀ ਉੱਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਲੌਗਇਨ ਦਾ ਆਮ ਕਾਰਨ ਹੈ।

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

sf org login web --instance-url https://acme--uat.sandbox.my.salesforce.com --alias uat
sf org display --target-org uat

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

ਕੈਸ਼ ਕੀਤੀ ਅਧਿਕਾਰਤਾ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ

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

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

ਸਥਾਨਕ ਰਿਕਾਰਡ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਉਪਨਾਮ ਅਤੇ org ਹੋਸਟ ਉਹ ਦੋ ਤੱਥ ਹਨ ਜੋ ਸਹਾਇਤਾ ਪੁੱਛੇਗੀ। ਉਪਨਾਮ ਹਟਾਉਣਾ ਉਲਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਘਟਨਾ ਦੇ ਵਿਚਕਾਰ ਗਲਤ ਹਟਾਉਣਾ ਸਿਰਫ਼ ਦੂਜੀ ਸਮੱਸਿਆ ਜੋੜਦਾ ਹੈ।

API ਬੇਨਤੀ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਰੱਦ ਹੁੰਦੀ ਹੈ

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

ਸਰੋਤ-ਪਤਾ ਪਾਬੰਦੀਆਂ ਉਹ ਸਥਿਤੀ ਹਨ ਜਿੱਥੇ ਲੌਗਇਨ ਚੱਲਦਾ ਹੈ ਪਰ ਕੁਏਰੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਫਲੋ ਅਤੇ API ਕਾਲ ਵੱਖਰੇ ਪਤਿਆਂ ਰਾਹੀਂ ਬਾਹਰ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਸਨੂੰ ਵੱਧ ਚੌੜੀ ਆਗਿਆ ਸੂਚੀ ਨਾਲ ਠੀਕ ਕਰਨਾ org ਮਾਲਕ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਸੁਵਿਧਾ ਨਹੀਂ, ਅਤੇ ਇਹ ਹੋਸਟ ਨੂੰ ਢਕਣ ਵਾਲੀ ਸਭ ਤੋਂ ਛੋਟੀ ਸੀਮਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

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

ਜੋ ਹੋਸਟ ਇਸਨੂੰ ਵਰਤੇਗਾ ਉੱਥੋਂ ਹੀ ਫਲੋ ਜਾਂਚੋ

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

ਜਾਂਚ ਲਈ ਹਾਨੀਰਹਿਤ ਅਧਿਕ੍ਰਿਤ ਪੜ੍ਹਤ ਵਰਤੋ, ਅਤੇ ਅਸਫਲ ਹੋਣ ਉੱਤੇ ਪਹਿਲੀ ਗਲਤੀ ਰੱਖੋ।

sf org list auth
sf org display --target-org uat
sf data query --target-org uat --query "select Id, Name from Organization"

ਜਦੋਂ ਲੌਗਇਨ ਸਫਲ ਹੁੰਦਾ ਹੈ ਪਰ ਕੁਏਰੀ ਅਸਫਲ, ਤਦ ਬਾਕੀ ਸੰਭਾਵੀ ਕਾਰਨ DNS, ਰੂਟਿੰਗ, TLS ਰੋਕ ਅਤੇ org ਵੱਲੋਂ ਕਲਾਇੰਟ ਨੀਤੀ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਮਾਲਕ ਹੈ। ਜਦੋਂ ਲੌਗਇਨ ਆਪ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਦ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ CLI ਸੰਭਵ ਤੌਰ ਤੇ ਇੱਕੋ ਹੋਸਟ ਉੱਤੇ ਨਹੀਂ, ਅਤੇ ਸੁਧਾਰ ਟਨਲ ਦਾ ਨਹੀਂ, ਉਹਨਾਂ ਵਿਚਕਾਰ ਦੀ ਵਿਵਸਥਾ ਦਾ ਹੈ। ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਹੋਰ ਨਿਯਮ ਮਿਲਦਾ ਹੈ: ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੇ ਕੰਮ ਲਈ ਮਨਜ਼ੂਰ ਪ੍ਰਮਾਣਪੱਤਰ-ਅਧਾਰਿਤ ਲੌਗਇਨ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਵਰਕਰ ਉੱਤੇ ਕਾਪੀ ਕੀਤਾ ਕੈਸ਼ ਸੈਸ਼ਨ ਪਛਾਣ ਦਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੈ।