Вхід у Salesforce CLI через VPN: CLI, браузер і хост API

Збої входу в Salesforce CLI повідомляють як одну проблему, а зазвичай їх три. Процес CLI працює десь, браузер, що завершує веб-потік, працює десь, і подальший виклик API працює десь, і ці три місця не зобов'язані ділити маршрут, резолвер або список дозволених. Порівняти їх — найшвидший спосіб з'ясувати, який із них насправді блокує тунель. Ніщо у виводі входу не вказує, який із трьох зазнав невдачі.

Три хости, одна історія входу

Веб-потік входу передає крок ідентифікації браузеру, і цей браузер часто на ноутбуці, поки CLI сидить на віддаленому хості розробки або в контейнері. На ноутбуці є клієнт VPN, на віддаленому хості є те, що дала йому команда платформи, і жодна з двох схем автоматично не покриває іншу. Значок VPN у рядку стану нічого не каже про хост, який жодного разу не запускав клієнт.

Після входу CLI робить власні запити до API звідти, де живе процес. Ці запити потребують DNS, маршрутизації, довіри TLS і авторизації клієнта на боці org — чотири окремі перевірки, і кожна може зазнати невдачі сама. Браузер, який чудово увійшов, нічого не каже ні про одну з них.

Тримайте обидві половини на одній часовій шкалі, але оцінюйте їх окремо. Тоді один тікет може сказати, яка половина зламалася, не перетворюючи це на суперечку про володіння.

Беріть запис org у org, а не з пам'яті

Веб-потік бере URL екземпляра і зберігає результат під псевдонімом, і обидва значення мають надходити від власника org, а не з історії термінала колеги. Хост sandbox, скопійований зі старого тікета, — часта причина входу, який автентифікується в неправильній 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, замість того щоб обходити їх скриптом, і ніколи не вставляйте пароль, ідентифікатор сеансу або зерно автентифікатора в shell-команду, щоб пропустити запит.

Що доводить кешована авторизація

Псевдонім у локальному списку авторизацій доводить, що вхід колись вдався на цій машині. Список читається з локального сховища і не звертається до 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, ймовірно, не на одному хості, і виправлення належить схемі між ними, а не тунелю. Автоматизація отримує ще одне правило: робота без нагляду потребує затвердженого входу на основі сертифіката, бо кешований інтерактивний сеанс, скопійований на worker, — не проєкт ідентичності.