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를 아직 보여 주는 탭이, 토큰 수명과 IP 제한과 클라이언트 앱 규칙이 API 경계에서 적용되기 때문에, CLI의 저장된 토큰이 현재 정책과 일치한다는 뜻은 아닙니다.

별칭과 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가 같은 호스트에 있지 않을 가능성이 크며, 수정은 터널이 아니라 둘 사이의 구성에 속합니다. 자동화에는 규칙이 하나 더 있는데, 캐시된 대화형 세션을 워커에 복사하는 것은 신원 설계가 아니므로 무인 작업에는 승인된 인증서 기반 로그인이 필요합니다.