Logowanie do Salesforce CLI przez VPN: CLI, przeglądarka i host API

Błędy logowania do Salesforce CLI są zgłaszane jako jeden problem, a zwykle są trzy. Proces CLI działa gdzieś, przeglądarka kończąca przepływ web działa gdzieś, a późniejsze wywołanie API działa gdzieś, i te trzy miejsca nie muszą dzielić trasy, resolwera ani listy dozwolonych. Porównanie ich to najszybszy sposób ustalenia, które z nich tunel faktycznie blokuje. Nic w danych wyjściowych logowania nie wskazuje, które z trzech zawiodło.

Trzy hosty, jedna historia logowania

Przepływ logowania web przekazuje krok tożsamości przeglądarce, a ta przeglądarka często jest na laptopie, podczas gdy CLI siedzi na zdalnym hoście deweloperskim lub w kontenerze. Laptop ma klienta VPN, zdalny host ma to, co dał mu zespół platformy, i żaden z tych układów nie obejmuje automatycznie drugiego. Ikona VPN na pasku stanu nie mówi nic o hoście, na którym klient nigdy nie działał.

Po zalogowaniu CLI wysyła własne żądania API z miejsca, w którym żyje proces. Te żądania potrzebują DNS, routingu, zaufania TLS i autoryzacji klienta po stronie org, czyli czterech osobnych kontroli i każda może zawieść sama. Przeglądarka, która zalogowała się pięknie, nie mówi ci nic o żadnej z nich.

Trzymaj obie połowy na jednej osi czasu, ale oceniaj je osobno. Wtedy jeden bilet może powiedzieć, która połowa się zepsuła, bez zamieniania tego w spór o własność.

Wpis org weź od org, nie z pamięci

Przepływ web pobiera URL instancji i zapisuje wynik pod aliasem, a obie wartości powinny pochodzić od właściciela org, a nie z historii terminala kolegi. Host sandbox skopiowany ze starego biletu to częsta przyczyna logowania, które uwierzytelnia się wobec niewłaściwego org, a potem zawodzi przy każdym zapytaniu.

Użyj formy udokumentowanej przez zainstalowaną wtyczkę, z własnym zatwierdzonym hostem i aliasem. Ta dokumentacja jest odniesieniem dla flag, które zmieniły się między sfdx a obecnym CLI.

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

Nazwa hosta i alias powyżej to przykłady, a nie wartości domyślne, które należy kopiować. Wykonaj zwykłe kroki tożsamości przeglądarki i MFA, zamiast obchodzić je skryptem, i nigdy nie umieszczaj hasła, identyfikatora sesji ani ziarna authenticatora w poleceniu powłoki, aby pominąć monit.

Co dowodzi autoryzacja w pamięci podręcznej

Alias widoczny na lokalnej liście autoryzacji dowodzi, że logowanie kiedyś się powiodło na tej maszynie. Lista jest czytana z lokalnego magazynu i nie kontaktuje się z org, aby potwierdzić, że token nadal działa, więc zdrowo wyglądający wpis i odrzucone wywołanie API mogą być jednocześnie prawdziwe. Traktuj pamięć podręczną jako zapis przeszłości, a nie test bieżącej łączności. Sprawdzenie pamięci podręcznej odpowiada na pytanie wsparcia, ale nigdy nie zamyka dochodzenia w sprawie łączności.

To samo rozróżnienie dotyczy sesji przeglądarki. Karta, która nadal pokazuje org, nie oznacza, że zapisany token CLI pasuje do obecnej polityki, ponieważ czas życia tokena, ograniczenia IP i reguły aplikacji klienckiej są egzekwowane na granicy API.

Przeczytaj lokalny wpis, zanim go usuniesz, bo alias i host org to dwa fakty, o które zapyta wsparcie. Usunięcie aliasu jest odwracalne, ale usunięcie niewłaściwego w środku incydentu tylko dodaje drugi problem.

Gdzie żądanie API jest naprawdę odrzucane

Śledź jedno żądanie od początku do końca i zanotuj, który komponent odpowiada. Błąd TLS nazywa inny problem niż 403, który nazywa inny problem niż przekroczenie czasu, a przekroczenie czasu jest jedynym z trzech, które wskazuje tunel jako pierwszego podejrzanego. Czytanie klasy błędu przed komunikatem oszczędza wiele domysłów. Zapisz klasę, zanim cokolwiek uruchomisz ponownie.

Ograniczenia adresu źródłowego to przypadek, który daje logowanie działające i zapytanie niedziałające, ponieważ przepływ przeglądarki i wywołanie API mogą wychodzić przez różne adresy. Naprawianie tego szerszą listą dozwolonych to decyzja właściciela org, a nie wygoda, i powinien to być najmniejszy zakres obejmujący host.

Zapisz zawodzące polecenie, alias, host wykonania i znacznik czasu, a token zostaw poza wszystkim, co wklejasz do biletu. To czterowierszowe podsumowanie jest tym, czego właściciel org potrzebuje, aby sprawdzić swoją stronę.

Sprawdź przepływ z hosta, który będzie go używał

Testuj z maszyny, która będzie wykonywać obciążenie. Logowanie zweryfikowane na laptopie nie mówi nic o agencie budowania w innej strefie sieci, a różnica jest dokładnie tym, czego próbujesz szukać.

Do sprawdzenia użyj nieszkodliwego dozwolonego odczytu, a jeśli zawiedzie, zachowaj pierwszy błąd.

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

Gdy logowanie się powiedzie, ale zapytanie zawiedzie, pozostałymi kandydatami są DNS, routing, przechwytywanie TLS i polityka klienta po stronie org, a każdy ma swojego właściciela. Gdy zawiedzie samo logowanie, przeglądarka i CLI prawdopodobnie nie są na tym samym hoście, a poprawka należy do układu między nimi, a nie do tunelu. Automatyzacja dostaje jeszcze jedną regułę: zadanie bez nadzoru potrzebuje zatwierdzonego logowania opartego na certyfikacie, bo zbuforowana sesja interaktywna skopiowana na workera nie jest projektem tożsamości.