Đăng nhập Salesforce CLI qua VPN: CLI, trình duyệt và máy chủ API

Các lỗi đăng nhập Salesforce CLI được báo cáo như một vấn đề và thường là ba. Tiến trình CLI chạy ở đâu đó, trình duyệt hoàn tất luồng web chạy ở đâu đó, và lệnh gọi API sau đó chạy ở đâu đó, và ba nơi đó không nhất thiết phải dùng chung tuyến đường, trình phân giải hay danh sách cho phép. So sánh chúng là cách nhanh nhất để biết đường hầm thực sự chặn cái nào. Không có gì trong đầu ra đăng nhập nói cái nào trong ba cái đã thất bại.

Ba máy chủ, một câu chuyện đăng nhập

Luồng đăng nhập web giao bước nhận dạng cho trình duyệt, và trình duyệt đó thường nằm trên máy tính xách tay của bạn trong khi CLI ngồi trên máy chủ phát triển từ xa hoặc trong vùng chứa. Máy tính xách tay có ứng dụng khách VPN, máy chủ từ xa có thứ mà nhóm nền tảng đã cấp, và không cấu hình nào tự động bao phủ cái kia. Biểu tượng VPN trên thanh trạng thái không nói gì về một máy chủ chưa từng chạy ứng dụng khách.

Sau khi đăng nhập, CLI thực hiện các yêu cầu API của riêng nó từ nơi tiến trình sống. Những yêu cầu đó cần DNS, định tuyến, tin cậy TLS và ủy quyền ứng dụng khách từ phía org, tức là bốn kiểm tra riêng biệt và mỗi cái có thể thất bại một mình. Một trình duyệt đã đăng nhập đẹp đẽ không nói gì với bạn về bất kỳ cái nào trong số đó.

Giữ cả hai nửa trên một dòng thời gian, nhưng cho điểm riêng. Khi đó một phiếu có thể nói nửa nào bị hỏng mà không biến nó thành tranh cãi về quyền sở hữu.

Lấy mục org từ org, không phải từ ký ức

Luồng web lấy URL phiên bản và lưu kết quả dưới một bí danh, và cả hai giá trị nên đến từ chủ sở hữu org thay vì lịch sử terminal của đồng nghiệp. Một máy chủ sandbox sao chép từ phiếu cũ là nguyên nhân phổ biến của việc đăng nhập xác thực nhầm org rồi thất bại ở mọi truy vấn.

Dùng hình thức mà plugin đã cài đặt ghi trong tài liệu, với máy chủ và bí danh đã được phê duyệt của riêng bạn. Tài liệu đó là tham chiếu cho các cờ đã thay đổi giữa sfdx và CLI hiện tại.

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

Tên máy chủ và bí danh ở trên là ví dụ, không phải giá trị mặc định mà bạn nên sao chép. Hoàn tất các bước nhận dạng trình duyệt và MFA thông thường thay vì viết kịch bản vòng qua chúng, và đừng bao giờ đặt mật khẩu, mã định danh phiên hay hạt giống trình xác thực vào một lệnh shell để bỏ qua lời nhắc.

Ủy quyền được lưu trong bộ nhớ đệm chứng minh điều gì

Một bí danh xuất hiện trong danh sách ủy quyền cục bộ chứng minh rằng đăng nhập đã từng thành công trên máy đó. Danh sách được đọc từ kho lưu trữ cục bộ và không liên hệ org để xác nhận token còn hoạt động, vì vậy một mục trông khỏe mạnh và một lệnh gọi API bị từ chối có thể cùng đúng. Hãy coi bộ nhớ đệm là bản ghi của quá khứ, không phải bài kiểm tra kết nối trực tiếp. Kiểm tra bộ nhớ đệm trả lời một câu hỏi hỗ trợ, nhưng không bao giờ kết thúc một cuộc điều tra kết nối.

Sự phân biệt tương tự áp dụng cho phiên trình duyệt. Một tab vẫn hiển thị org không có nghĩa là token đã lưu của CLI khớp với chính sách hiện tại, vì thời hạn token, giới hạn IP và quy tắc ứng dụng khách được thực thi tại ranh giới API.

Đọc bản ghi cục bộ trước khi xóa nó, vì bí danh và máy chủ org là hai dữ kiện mà bộ phận hỗ trợ sẽ hỏi. Xóa một bí danh là có thể đảo ngược, nhưng xóa nhầm cái sai giữa một sự cố chỉ thêm vấn đề thứ hai.

Nơi yêu cầu API thực sự bị từ chối

Theo dõi một yêu cầu từ đầu đến cuối và ghi lại thành phần nào trả lời. Lỗi TLS gọi tên một vấn đề khác với 403, mà lại gọi tên một vấn đề khác với hết thời gian, và hết thời gian là cái duy nhất trong ba cái chỉ vào đường hầm như nghi phạm đầu tiên. Đọc lớp lỗi trước thông điệp tiết kiệm rất nhiều phỏng đoán. Ghi lớp đó trước khi chạy lại bất cứ thứ gì.

Hạn chế địa chỉ nguồn là trường hợp tạo ra đăng nhập hoạt động và truy vấn không hoạt động, vì luồng trình duyệt và lệnh gọi API có thể đi ra qua các địa chỉ khác nhau. Sửa điều đó bằng một danh sách cho phép rộng hơn là quyết định của chủ sở hữu org, không phải sự tiện lợi, và nên là phạm vi nhỏ nhất bao phủ máy chủ.

Ghi lại lệnh thất bại, bí danh, máy chủ thực thi và dấu thời gian, và để token ra ngoài mọi thứ bạn dán vào phiếu. Bản tóm tắt bốn dòng đó là thứ chủ sở hữu org cần để kiểm tra phía của họ.

Kiểm tra luồng từ chính máy chủ sẽ dùng nó

Kiểm tra từ máy sẽ chạy khối lượng công việc. Một lần đăng nhập đã xác minh trên máy tính xách tay của bạn không nói gì về một tác nhân build ở vùng mạng khác, và sự khác biệt chính là thứ bạn đang cố tìm.

Dùng một lần đọc được ủy quyền vô hại cho việc kiểm tra, và nếu thất bại hãy giữ lỗi đầu tiên.

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

Khi đăng nhập thành công nhưng truy vấn thất bại, các ứng viên còn lại là DNS, định tuyến, chặn TLS và chính sách ứng dụng khách phía org, và mỗi cái có chủ sở hữu riêng. Khi bản thân đăng nhập thất bại, trình duyệt và CLI có lẽ không ở cùng một máy chủ, và cách sửa thuộc về cách bố trí giữa chúng chứ không phải đường hầm. Tự động hóa có thêm một quy tắc: một công việc không có người giám sát cần đăng nhập được phê duyệt dựa trên chứng chỉ, vì một phiên tương tác đã lưu trong bộ nhớ đệm và sao chép sang worker không phải là thiết kế nhận dạng.