Log masuk Salesforce CLI melalui VPN: CLI, pelayar dan hos API

Kegagalan log masuk Salesforce CLI dilaporkan sebagai satu masalah dan biasanya ada tiga. Proses CLI berjalan di suatu tempat, pelayar yang melengkapkan aliran web berjalan di suatu tempat, dan panggilan API kemudian berjalan di suatu tempat, dan ketiga-tiga tempat itu tidak perlu berkongsi laluan, penyelesai atau senarai benaran. Membandingkannya ialah cara terpantas untuk mengetahui yang mana sebenarnya disekat oleh terowong. Tiada apa-apa dalam output log masuk yang menyatakan yang mana antara tiga itu gagal.

Tiga hos, satu kisah log masuk

Aliran log masuk web menyerahkan langkah identiti kepada pelayar, dan pelayar itu selalunya ada pada komputer riba anda sementara CLI duduk di hos pembangunan jauh atau dalam kontena. Komputer riba mempunyai klien VPN, hos jauh mempunyai apa sahaja yang diberikan oleh pasukan platform, dan tiada satu pun daripada kedua-dua susunan itu menutup yang lain secara automatik. Ikon VPN dalam bar status tidak mengatakan apa-apa tentang hos yang tidak pernah menjalankan klien.

Selepas log masuk, CLI membuat permintaan APInya sendiri dari tempat proses itu hidup. Permintaan itu memerlukan DNS, penghalaan, kepercayaan TLS dan kebenaran klien di pihak org, iaitu empat pemeriksaan berasingan dan setiap satu boleh gagal sendiri. Pelayar yang log masuk dengan cantik tidak memberitahu anda apa-apa tentang mana-mana daripadanya.

Simpan kedua-dua bahagian pada satu garis masa, tetapi nilaikan secara berasingan. Kemudian satu tiket boleh menyatakan bahagian mana yang rosak tanpa menjadikannya perdebatan tentang pemilikan.

Ambil entri org daripada org, bukan daripada ingatan

Aliran web mengambil URL instans dan menyimpan hasilnya di bawah alias, dan kedua-dua nilai harus datang daripada pemilik org dan bukan daripada sejarah terminal rakan sekerja. Hos sandbox yang disalin daripada tiket lama ialah punca biasa log masuk yang mengesahkan terhadap org yang salah dan kemudian gagal pada setiap pertanyaan.

Gunakan bentuk yang didokumenkan oleh pemalam yang dipasang, dengan hos dan alias anda sendiri yang diluluskan. Dokumentasi itu ialah rujukan untuk bendera yang berubah antara sfdx dan CLI semasa.

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

Nama hos dan alias di atas ialah contoh, bukan nilai lalai yang patut anda salin. Lengkapkan langkah identiti pelayar dan MFA biasa dan bukan memintasnya dengan skrip, dan jangan sekali-kali meletakkan kata laluan, pengecam sesi atau benih pengesah dalam arahan shell untuk melangkau gesaan.

Apa yang dibuktikan oleh kebenaran yang dicache

Alias yang muncul dalam senarai kebenaran tempatan membuktikan bahawa log masuk pernah berjaya pada mesin itu. Senarai itu dibaca daripada storan tempatan dan tidak menghubungi org untuk mengesahkan token masih berfungsi, jadi entri yang kelihatan sihat dan panggilan API yang ditolak boleh kedua-duanya benar. Anggap cache sebagai rekod masa lalu, bukan sebagai ujian ketersambungan secara langsung. Semakan cache menjawab soalan sokongan, tetapi ia tidak pernah menutup siasatan ketersambungan.

Perbezaan yang sama terpakai pada sesi pelayar. Tab yang masih menunjukkan org tidak bermakna token tersimpan CLI sepadan dengan dasar semasa, kerana jangka hayat token, sekatan IP dan peraturan aplikasi klien dikuatkuasakan pada sempadan API.

Baca rekod tempatan sebelum memadamnya, kerana alias dan hos org ialah dua fakta yang akan ditanya oleh sokongan. Mengalih keluar alias boleh diterbalikkan, tetapi mengalih keluar yang salah di tengah-tengah insiden hanya menambah masalah kedua.

Di mana permintaan API sebenarnya ditolak

Jejaki satu permintaan dari awal hingga akhir dan catat komponen mana yang menjawab. Kegagalan TLS menamakan masalah yang berbeza daripada 403, yang menamakan masalah yang berbeza daripada tamat masa, dan tamat masa ialah satu-satunya daripada tiga yang menunjuk terowong sebagai suspek pertama. Membaca kelas ralat sebelum mesej menjimatkan banyak tekaan. Tulis kelas itu sebelum menjalankan semula apa-apa.

Sekatan alamat sumber ialah kes yang menghasilkan log masuk yang berfungsi dan pertanyaan yang tidak, kerana aliran pelayar dan panggilan API boleh keluar melalui alamat yang berbeza. Membetulkannya dengan senarai benaran yang lebih luas ialah keputusan pemilik org, bukan kemudahan, dan ia sepatutnya menjadi julat terkecil yang meliputi hos itu.

Tangkap arahan yang gagal, alias, hos pelaksanaan dan cap masa, dan biarkan token di luar apa sahaja yang anda tampal ke dalam tiket. Ringkasan empat baris itu ialah apa yang pemilik org perlukan untuk memeriksa pihak mereka.

Semak aliran daripada hos yang akan menggunakannya

Uji daripada mesin yang akan menjalankan beban kerja. Log masuk yang disahkan pada komputer riba anda tidak memberitahu apa-apa tentang ejen binaan di zon rangkaian lain, dan perbezaannya ialah tepat apa yang anda cuba cari.

Gunakan pembacaan dibenarkan yang tidak berbahaya untuk semakan, dan simpan ralat pertama jika ia gagal.

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

Apabila log masuk berjaya tetapi pertanyaan gagal, calon yang tinggal ialah DNS, penghalaan, pemintasan TLS dan dasar klien di pihak org, dan setiap satu mempunyai pemiliknya sendiri. Apabila log masuk itu sendiri gagal, pelayar dan CLI mungkin tidak berada pada hos yang sama, dan pembetulannya tergolong dalam susunan antara mereka dan bukan pada terowong. Automasi mendapat satu lagi peraturan: kerja tanpa pengawasan memerlukan log masuk diluluskan berasaskan sijil, kerana sesi interaktif yang dicache dan disalin kepada pekerja bukanlah reka bentuk identiti.