VPN üzerinden Salesforce CLI oturum açma: CLI, tarayıcı ve API ana makinesi

Salesforce CLI oturum açma hataları tek bir sorun olarak bildirilir ve genellikle üçtür. CLI süreci bir yerde çalışır, web akışını tamamlayan tarayıcı başka bir yerde çalışır ve sonraki API çağrısı da bir yerde çalışır, ve bu üç yerin bir rotayı, çözümleyiciyi veya izin listesini paylaşması gerekmez. Onları karşılaştırmak, tünelin gerçekte hangisini engellediğini bulmanın en hızlı yoludur. Oturum açma çıktısında üçünden hangisinin başarısız olduğu yazmaz.

Üç ana makine, tek bir oturum açma hikâyesi

Web oturum açma akışı kimlik adımını bir tarayıcıya devreder ve bu tarayıcı genellikle dizüstü bilgisayarınızdadır; CLI ise uzak bir geliştirme ana makinesinde veya bir konteynerde oturur. Dizüstünde VPN istemcisi vardır, uzak ana makinede platform ekibinin verdiği şey vardır ve iki düzenlemeden hiçbiri diğerini otomatik olarak kapsamaz. Durum çubuğundaki VPN simgesi, istemciyi hiç çalıştırmamış bir ana makine hakkında hiçbir şey söylemez.

Oturum açtıktan sonra CLI kendi API isteklerini sürecin yaşadığı yerden yapar. Bu istekler DNS, yönlendirme, TLS güveni ve org tarafında istemci yetkilendirmesi gerektirir; bunlar dört ayrı denetimdir ve her biri tek başına başarısız olabilir. Güzelce oturum açmış bir tarayıcı bunların hiçbiri hakkında size bir şey söylemez.

İki yarıyı tek bir zaman çizelgesinde tutun, ancak ayrı ayrı puanlayın. O zaman tek bir bilet, sahiplik tartışmasına dönüşmeden hangi yarının bozulduğunu söyleyebilir.

Org girdisini org'dan alın, bellekten değil

Web akışı bir örnek URL alır ve sonucu bir takma ad altında saklar, ve her iki değer de meslektaşınızın terminal geçmişinden değil org sahibinden gelmelidir. Eski bir biletten kopyalanmış bir sandbox ana makinesi, yanlış org'a karşı kimlik doğrulayan ve ardından her sorguda başarısız olan bir oturum açmanın yaygın nedenidir.

Kurulu eklentinin belgelediği biçimi, kendi onaylı ana makineniz ve takma adınızla kullanın. O belgeler, sfdx ile mevcut CLI arasında değişen bayraklar için referanstır.

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

Yukarıdaki ana makine adı ve takma ad örneklerdir, kopyalamanız gereken varsayılanlar değildir. Betikle etrafından dolaşmak yerine normal tarayıcı kimlik ve MFA adımlarını tamamlayın, ve istemi atlamak için asla bir kabuk komutuna parola, oturum tanımlayıcısı veya kimlik doğrulayıcı tohumu koymayın.

Önbelleğe alınmış yetkilendirme neyi kanıtlar

Yerel yetkilendirme listesinde görünen bir takma ad, oturum açmanın bir zamanlar o makinede başarılı olduğunu kanıtlar. Liste yerel depolamadan okunur ve token'ın hâlâ çalıştığını doğrulamak için org'la iletişim kurmaz, bu yüzden sağlıklı görünen bir kayıt ve reddedilen bir API çağrısı aynı anda doğru olabilir. Önbelleği geçmişin kaydı olarak görün, canlı bağlantı testi olarak değil. Bir önbellek denetimi bir destek sorusunu yanıtlar, ancak bir bağlantı araştırmasını asla kapatmaz.

Aynı ayrım tarayıcı oturumu için de geçerlidir. Org'u hâlâ gösteren bir sekme, CLI'nin sakladığı token'ın mevcut politikayla eşleştiği anlamına gelmez, çünkü token ömrü, IP kısıtlamaları ve istemci uygulaması kuralları API sınırında uygulanır.

Yerel kaydı silmeden önce okuyun, çünkü takma ad ve org ana makinesi desteğin soracağı iki gerçektir. Bir takma adı kaldırmak geri alınabilir, ancak yanlış olanı bir olayın ortasında kaldırmak yalnızca ikinci bir sorun ekler.

API isteğinin gerçekte nerede reddedildiği

Bir isteği baştan sona izleyin ve hangi bileşenin yanıt verdiğini not edin. TLS hatası 403'ten farklı bir sorunu adlandırır, o da zaman aşımından farklı bir sorunu adlandırır ve zaman aşımı üçünden yalnızca tüneli ilk şüpheli olarak gösterir. Hata sınıfını mesajdan önce okumak çok fazla tahmin tasarrufu sağlar. Herhangi bir şeyi yeniden çalıştırmadan önce sınıfı yazın.

Kaynak adres kısıtlamaları, oturum açmanın çalışıp sorgunun çalışmadığı durumdur, çünkü tarayıcı akışı ve API çağrısı farklı adreslerden çıkabilir. Bunu daha geniş bir izin listesiyle düzeltmek org sahibinin kararıdır, kolaylık değil, ve ana makineyi kapsayan en küçük aralık olmalıdır.

Başarısız olan komutu, takma adı, yürütme ana makinesini ve zaman damgasını kaydedin ve token'ı bilete yapıştırdığınız her şeyin dışında tutun. O dört satırlık özet, org sahibinin kendi tarafını kontrol etmek için ihtiyaç duyduğu şeydir.

Akışı onu kullanacak ana makineden denetleyin

İş yükünü çalıştıracak makineden test edin. Dizüstü bilgisayarınızda doğrulanmış bir oturum açma, başka bir ağ bölgesindeki bir build aracısı hakkında hiçbir şey söylemez ve fark tam olarak bulmaya çalıştığınız şeydir.

Denetim için zararsız bir yetkili okuma kullanın ve başarısız olursa ilk hatayı saklayın.

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

Oturum açma başarılı olup sorgu başarısız olduğunda, kalan adaylar DNS, yönlendirme, TLS araya girme ve org tarafında istemci politikasıdır ve her birinin kendi sahibi vardır. Oturum açmanın kendisi başarısız olduğunda, tarayıcı ve CLI muhtemelen aynı ana makinede değildir ve düzeltme tünele değil aralarındaki düzene aittir. Otomasyon bir kural daha alır: gözetimsiz bir iş, onaylı sertifika tabanlı oturum açma gerektirir, çünkü bir çalışana kopyalanmış önbelleğe alınmış etkileşimli oturum bir kimlik tasarımı değildir.