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 ಮಾಲೀಕರಿಗೆ ತಮ್ಮ ಬದಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ಬೇಕಾದದ್ದು.

ಬಳಸುವ ಹೋಸ್ಟ್ನಿಂದಲೇ ಹರಿವನ್ನು ಪರಿಶೀಲಿಸಿ

ಕೆಲಸದ ಹೊರೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಯಂತ್ರದಿಂದ ಪರೀಕ್ಷಿಸಿ. ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿದ ಲಾಗಿನ್ ಬೇರೆ ನೆಟ್ವರ್ಕ್ ವಲಯದ build ಏಜೆಂಟ್ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ವ್ಯತ್ಯಾಸವೇ ನೀವು ಹುಡುಕುತ್ತಿರುವುದು.

ಪರಿಶೀಲನೆಗೆ ನಿರುಪದ್ರವ ಅನುಮತಿತ ಓದನ್ನು ಬಳಸಿ, ಮತ್ತು ವಿಫಲವಾದರೆ ಮೊದಲ ದೋಷವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.

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 ಒಂದೇ ಹೋಸ್ಟ್ನಲ್ಲಿಲ್ಲದಿರಬಹುದು, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಟನೆಲ್ಗೆ ಅಲ್ಲ, ಅವುಗಳ ನಡುವಿನ ವ್ಯವಸ್ಥೆಗೆ ಸೇರಿದ್ದು. ಸ್ವಯಂಚಾಲನೆಗೆ ಇನ್ನೊಂದು ನಿಯಮ ಸಿಗುತ್ತದೆ: ಮೇಲ್ವಿಚಾರಣೆ ಇಲ್ಲದ ಕೆಲಸಕ್ಕೆ ಅನುಮೋದಿತ ಪ್ರಮಾಣಪತ್ರ ಆಧಾರಿತ ಲಾಗಿನ್ ಬೇಕು, ಏಕೆಂದರೆ ವರ್ಕರ್ಗೆ ನಕಲಿಸಿದ ಕ್ಯಾಶ್ ಮಾಡಿದ ಸಂವಾದಾತ್ಮಕ ಸೆಷನ್ ಗುರುತಿನ ವಿನ್ಯಾಸವಲ್ಲ.