VPN üzərindən Salesforce CLI girişi: CLI, brauzer və API hostu

Salesforce CLI giriş xətaları bir problem kimi bildirilir, halbuki adətən üçdür. CLI prosesi bir yerdə işləyir, veb axınını tamamlayan brauzer başqa bir yerdə işləyir, sonrakı API çağırışı da bir yerdə işləyir və bu üç yer marşrutu, həlledicini və ya icazə siyahısını paylaşmağa borclu deyil. Onları müqayisə etmək tunelin əslində hansını blokladığını tapmağın ən sürətli yoludur. Giriş çıxışında üçündən hansının uğursuz olduğu göstərilmir.

Üç host, bir giriş hekayəsi

Veb giriş axını kimlik addımını brauzerə verir və bu brauzer çox vaxt noutbukdadır, CLI isə uzaq inkişaf hostunda və ya konteynerdə oturur. Noutbukda VPN müştərisi var, uzaq hostda platforma komandasının verdiyi şey var və heç bir düzən digərini avtomatik əhatə etmir. Status zolağındakı VPN ikonu müştərini heç vaxt işə salmamış host haqqında heç nə demir.

Girişdən sonra CLI öz API sorğularını prosesin yaşadığı yerdən edir. Bu sorğular DNS, marşrutlaşdırma, TLS etimadı və orqanizasiya tərəfində müştəri avtorizasiyası tələb edir ki, bunlar hər biri ayrıca uğursuz ola bilən dörd ayrı yoxlamadır. Gözəl giriş etmiş brauzer onlardan heç biri haqqında sizə heç nə demir.

Hər iki yarını bir zaman xəttində saxlayın, amma ayrıca qiymətləndirin. Onda bir bilet hansı yarının pozulduğunu sahiblik mübahisəsinə çevirmədən deyə bilər.

Orqanizasiya qeydini yaddaşdan deyil, orqanizasiyadan götürün

Veb axın instansiya URL-i götürür və nəticəni ləqəb altında saxlayır, hər iki dəyər də həmkarın terminal tarixçəsindən deyil, orqanizasiya sahibindən gəlməlidir. Köhnə biletdən kopyalanmış sandbox hostu səhv orqanizasiyaya autentifikasiya edən və sonra hər sorğuda uğursuz olan girişin geniş yayılmış səbəbidir.

Quraşdırılmış plaqinin sənədləşdirdiyi formanı, öz təsdiqlənmiş hostunuz və ləqəbinizlə istifadə edin. Bu sənədlər sfdx ilə cari CLI arasında dəyişən bayraqlar üçün arayışdır.

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

Yuxarıdakı host adı və ləqəb nümunədir, kopyalamalı olduğunuz standart dəyərlər deyil. Adi brauzer kimlik və MFA addımlarını tamamlayın, onların ətrafından skriptlə yan keçməyin, və sorğunu keçmək üçün heç vaxt qabıq əmrinə parol, sessiya identifikatoru və ya autentifikator toxumu yerləşdirməyin.

Keşlənmiş avtorizasiya nəyi sübut edir

Yerli avtorizasiya siyahısında görünən ləqəb həmin maşında girişin bir dəfə uğurlu olduğunu sübut edir. Siyahı yerli yaddaşdan oxunur və tokenin hələ işlədiyini təsdiqləmək üçün orqanizasiya ilə əlaqə saxlamır, buna görə sağlam görünən qeyd və rədd edilmiş API çağırışı eyni vaxtda doğru ola bilər. Keşə keçmişin qeydi kimi yanaşın, canlı bağlantı testi kimi yox. Keş yoxlaması dəstək sualına cavab verir, lakin bağlantı araşdırmasını heç vaxt bağlamır.

Eyni fərq brauzer sessiyasına da aiddir. Orqanizasiyanı hələ göstərən vərəq CLI-nin saxladığı tokenin cari siyasətə uyğun olduğunu demir, çünki token ömrü, IP məhdudiyyətləri və müştəri tətbiqi qaydaları API sərhədində tətbiq olunur.

Yerli qeydi silməzdən əvvəl oxuyun, çünki ləqəb və orqanizasiya hostu dəstəyin soruşacağı iki faktdır. Ləqəbi silmək geri qaytarıla bilər, amma hadisənin ortasında səhv olanı silmək sadəcə ikinci problem əlavə edir.

API sorğusu əslində harada rədd edilir

Bir sorğunu başdan sona izləyin və hansı komponentin cavab verdiyini qeyd edin. TLS xətası 403-dən fərqli problemi adlandırır, o da fasilədən fərqli problemi adlandırır və fasilə üçündən yalnız tuneli ilk şübhəli kimi göstərəndir. Xəta sinfini mesajdan əvvəl oxumaq çoxlu təxmini qənaət edir. Hər şeyi yenidən işə salmadan əvvəl sinfi yazın.

Mənbə ünvanı məhdudiyyətləri işləyən giriş və işləməyən sorğu yaradan haldır, çünki brauzer axını və API çağırışı fərqli ünvanlardan çıxa bilər. Bunu daha geniş icazə siyahısı ilə düzəltmək rahatlıq deyil, orqanizasiya sahibinin qərarıdır və hostu əhatə edən ən kiçik aralıq olmalıdır.

Uğursuz əmri, ləqəbi, icra hostunu və vaxt möhürünü qeyd edin, tokeni biletdə yapışdırdığınız hər şeydən kənarda saxlayın. Dörd sətirlik bu xülasə orqanizasiya sahibinin öz tərəfini yoxlamaq üçün ehtiyac duyduğu şeydir.

Axını ondan istifadə edəcək hostdan yoxlayın

İş yükünü işlədəcək maşından test edin. Noutbukunuzda təsdiqlənmiş giriş başqa şəbəkə zonasındakı build agenti barədə heç nə demir və fərq elə tapmağa çalışdığınız şeydir.

Yoxlama üçün zərərsiz icazəli oxuma istifadə edin və uğursuz olsa ilk xətanı saxlayın.

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

Giriş uğurlu olub sorğu uğursuz olduqda qalan namizədlər DNS, marşrutlaşdırma, TLS ələ keçirmə və orqanizasiya tərəfində müştəri siyasətidir və hər birinin öz sahibi var. Girişin özü uğursuz olduqda brauzer və CLI çox güman ki eyni hostda deyil və düzəliş tunelə deyil, onların arasındakı düzənə aiddir. Avtomatlaşdırma bir qayda daha alır: nəzarətsiz iş təsdiqlənmiş sertifikat əsaslı giriş tələb edir, çünki işçiyə kopyalanmış keşlənmiş interaktiv sessiya kimlik dizaynı deyil.