Login Salesforce CLI melalui VPN: CLI, Browser, dan Host API

Kegagalan login Salesforce CLI dilaporkan sebagai satu masalah dan biasanya ada tiga. Proses CLI berjalan di suatu tempat, browser yang menyelesaikan alur web berjalan di suatu tempat, dan panggilan API berikutnya berjalan di suatu tempat, dan ketiga tempat itu tidak harus berbagi rute, resolver, atau daftar izin. Membandingkannya adalah cara tercepat untuk mengetahui mana yang sebenarnya diblokir terowongan. Tidak ada apa pun di keluaran login yang menyebutkan mana dari ketiganya yang gagal.

Tiga host, satu kisah login

Alur login web menyerahkan langkah identitas ke browser, dan browser itu sering ada di laptop Anda sementara CLI duduk di host pengembangan jarak jauh atau di dalam kontainer. Laptop memiliki klien VPN, host jarak jauh memiliki apa pun yang diberikan tim platform, dan tidak ada dari kedua pengaturan itu yang otomatis mencakup yang lain. Ikon VPN di bilah status tidak mengatakan apa pun tentang host yang tidak pernah menjalankan klien.

Setelah login, CLI membuat permintaan API-nya sendiri dari tempat proses itu hidup. Permintaan itu membutuhkan DNS, perutean, kepercayaan TLS, dan otorisasi klien di sisi org, yang merupakan empat pemeriksaan terpisah dan masing-masing dapat gagal sendiri. Browser yang berhasil masuk dengan indah tidak memberi tahu Anda apa pun tentang salah satunya.

Simpan kedua bagian pada satu garis waktu, tetapi nilai keduanya secara terpisah. Dengan begitu satu tiket dapat menyebutkan bagian mana yang rusak tanpa mengubahnya menjadi perdebatan tentang kepemilikan.

Ambil entri org dari org, bukan dari ingatan

Alur web mengambil URL instans dan menyimpan hasilnya di bawah alias, dan kedua nilai harus berasal dari pemilik org, bukan dari riwayat terminal rekan kerja. Host sandbox yang disalin dari tiket lama adalah penyebab umum login yang mengautentikasi ke org yang salah lalu gagal pada setiap kueri.

Gunakan bentuk yang didokumentasikan plugin yang terpasang, dengan host dan alias yang Anda setujui sendiri. Dokumentasi itu adalah rujukan untuk flag yang berubah antara sfdx dan CLI saat ini.

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

Nama host dan alias di atas adalah contoh, bukan nilai default yang harus Anda salin. Selesaikan langkah identitas browser dan MFA yang normal alih-alih mengakalinya dengan skrip, dan jangan pernah menaruh kata sandi, pengenal sesi, atau benih autentikator dalam perintah shell untuk melewati perintah itu.

Apa yang dibuktikan otorisasi yang di-cache

Alias yang muncul di daftar otorisasi lokal membuktikan bahwa login pernah berhasil di mesin itu. Daftar itu dibaca dari penyimpanan lokal dan tidak menghubungi org untuk memastikan token masih berfungsi, jadi entri yang tampak sehat dan panggilan API yang ditolak bisa sama-sama benar. Perlakukan cache sebagai catatan masa lalu, bukan sebagai uji konektivitas hidup. Pemeriksaan cache menjawab pertanyaan dukungan, tetapi tidak pernah menutup penyelidikan konektivitas.

Pembedaan yang sama berlaku untuk sesi browser. Tab yang masih menampilkan org tidak berarti token tersimpan CLI cocok dengan kebijakan saat ini, karena masa pakai token, pembatasan IP, dan aturan aplikasi klien ditegakkan di batas API.

Baca catatan lokal sebelum menghapusnya, karena alias dan host org adalah dua fakta yang akan diminta dukungan. Menghapus alias dapat dibatalkan, tetapi menghapus yang salah di tengah insiden hanya menambah masalah kedua.

Di mana permintaan API sebenarnya ditolak

Lacak satu permintaan dari awal hingga akhir dan catat komponen mana yang menjawab. Kegagalan TLS menyebutkan masalah yang berbeda dari 403, yang menyebutkan masalah yang berbeda dari batas waktu, dan batas waktu adalah satu-satunya dari ketiganya yang menunjuk terowongan sebagai tersangka pertama. Membaca kelas kesalahan sebelum pesannya menghemat banyak dugaan. Tulis kelas itu sebelum menjalankan ulang apa pun.

Pembatasan alamat sumber adalah kasus yang menghasilkan login yang berfungsi dan kueri yang tidak, karena alur browser dan panggilan API dapat keluar melalui alamat yang berbeda. Memperbaikinya dengan daftar izin yang lebih luas adalah keputusan pemilik org, bukan kenyamanan, dan itu harus menjadi rentang terkecil yang mencakup host.

Catat perintah yang gagal, alias, host eksekusi, dan stempel waktu, dan jangan sertakan token dalam apa pun yang Anda tempelkan ke tiket. Ringkasan empat baris itulah yang dibutuhkan pemilik org untuk memeriksa sisinya.

Periksa alur dari host yang akan menggunakannya

Uji dari mesin yang akan menjalankan beban kerja. Login yang diverifikasi di laptop Anda tidak mengatakan apa pun tentang agen build di zona jaringan lain, dan perbedaannya persis apa yang ingin Anda temukan.

Gunakan pembacaan resmi yang tidak berbahaya untuk pemeriksaan, dan simpan kesalahan pertama jika gagal.

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

Ketika login berhasil tetapi kueri gagal, kandidat yang tersisa adalah DNS, perutean, intersepsi TLS, dan kebijakan klien di sisi org, dan masing-masing punya pemiliknya. Ketika login itu sendiri gagal, browser dan CLI mungkin tidak berada di host yang sama, dan perbaikannya milik pengaturan di antara keduanya, bukan terowongan. Otomasi mendapat satu aturan lagi: pekerjaan tanpa pengawasan membutuhkan login berbasis sertifikat yang disetujui, karena sesi interaktif yang di-cache dan disalin ke worker bukanlah desain identitas.