Salesforce CLI-ში შესვლა VPN-ით: CLI, ბრაუზერი და API ჰოსტი

Salesforce CLI-ში შესვლის წარუმატებლობა ერთ პრობლემად ფიქსირდება და ჩვეულებრივ სამია. CLI პროცესი სადღაც მუშაობს, ვებ ნაკადს დამამთავრებელი ბრაუზერი სადღაც მუშაობს, და შემდგომი API გამოძახება სადღაც მუშაობს, და ამ სამ ადგილს არ უნდა ჰქონდეს საერთო მარშრუტი, გამხსნელი ან ნებადართულთა სია. მათი შედარება ყველაზე სწრაფი გზაა იმის გასაგებად, რომელი ბლოკავს გვირაბს სინამდვილეში. შესვლის გამოსავალში არაფერი არ ამბობს, სამიდან რომელი ჩავარდა.

სამი ჰოსტი, ერთი შესვლის ისტორია

ვებ შესვლის ნაკადი იდენტობის ნაბიჯს ბრაუზერს გადასცემს, და ეს ბრაუზერი ხშირად თქვენს ლეპტოპზეა, სანამ CLI დისტანციურ განვითარების ჰოსტზე ან კონტეინერში ზის. ლეპტოპს VPN კლიენტი აქვს, დისტანციურ ჰოსტს აქვს ის, რაც პლატფორმის გუნდმა მისცა, და არც ერთი ეს განლაგება ავტომატურად არ ფარავს მეორეს. სტატუსის ზოლში VPN ხატულა არაფერს ამბობს ჰოსტზე, რომელსაც კლიენტი არასოდეს გაუშვია.

შესვლის შემდეგ CLI საკუთარ API მოთხოვნებს აგზავნის იქიდან, სადაც პროცესი ცხოვრობს. ამ მოთხოვნებს სჭირდება DNS, მარშრუტიზაცია, TLS ნდობა და კლიენტის ავტორიზაცია org-ის მხრიდან, რაც ოთხი ცალკე შემოწმებაა და თითოეული დამოუკიდებლად შეიძლება ჩავარდეს. ლამაზად შესული ბრაუზერი არც ერთ მათგანზე არაფერს გეუბნებათ.

ორივე ნახევარი ერთ ქრონოლოგიაზე შეინახეთ, მაგრამ ცალკე შეაფასეთ. მაშინ ერთი ბილეთი იტყვის, რომელი ნახევარი გატყდა, საკუთრების შესახებ კამათად ქცევის გარეშე.

org-ის ჩანაწერი აიღეთ org-იდან, არა მეხსიერებიდან

ვებ ნაკადი იღებს ინსტანციის URL-ს და შედეგს ინახავს ფსევდონიმის ქვეშ, და ორივე მნიშვნელობა უნდა მოვიდეს org-ის მფლობელისგან და არა კოლეგის ტერმინალის ისტორიიდან. ძველი ბილეთიდან კოპირებული sandbox ჰოსტი ჩვეულებრივი მიზეზია იმისა, რომ შესვლა არასწორ org-ს ავთენტიფიცირებს და შემდეგ ყველა მოთხოვნაზე ჩავარდება.

გამოიყენეთ ფორმა, რომელსაც დაინსტალირებული პლაგინი ადასტურებს, საკუთარი დამტკიცებული ჰოსტითა და ფსევდონიმით. ის დოკუმენტაცია მითითებაა დროშებისთვის, რომლებიც sfdx-სა და მიმდინარე CLI-ს შორის შეიცვალა.

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

ზემოთ მოცემული ჰოსტის სახელი და ფსევდონიმი მაგალითებია, არა ნაგულისხმევი მნიშვნელობები, რომლებიც უნდა დააკოპიროთ. დაასრულეთ ბრაუზერის იდენტობისა და MFA-ის ჩვეულებრივი ნაბიჯები, ნაცვლად სკრიპტით მათი გვერდის ავლისა, და არასოდეს ჩასვათ პაროლი, სესიის იდენტიფიკატორი ან ავთენტიფიკატორის თესლი shell ბრძანებაში მოთხოვნის გამოტოვებისთვის.

რას ამტკიცებს ქეშირებული ავტორიზაცია

ადგილობრივი ავტორიზაციის სიაში გამოჩენილი ფსევდონიმი ამტკიცებს, რომ შესვლა ერთხელ წარმატებით დასრულდა იმ მანქანაზე. სია იკითხება ადგილობრივი საცავიდან და არ უკავშირდება org-ს იმის დასადგენად, რომ ტოკენი ჯერ კიდევ მუშაობს, ამიტომ ჯანსაღად გამომყურებელი ჩანაწერი და უარყოფილი API გამოძახება შეიძლება ერთდროულად ჭეშმარიტი იყოს. ქეშს მოეპყარით როგორც წარსულის ჩანაწერს, არა როგორც ცოცხალი კავშირის ტესტს. ქეშის შემოწმება პასუხობს მხარდაჭერის კითხვას, მაგრამ არასოდეს ხურავს კავშირის გამოძიებას.

იგივე განსხვავება ვრცელდება ბრაუზერის სესიაზეც. ჩანართი, რომელიც ჯერ კიდევ აჩვენებს org-ს, არ ნიშნავს, რომ CLI-ის შენახული ტოკენი შეესაბამება მიმდინარე პოლიტიკას, რადგან ტოკენის სიცოცხლე, IP შეზღუდვები და კლიენტის აპლიკაციის წესები API-ის საზღვარზე აღსრულდება.

წაიკითხეთ ადგილობრივი ჩანაწერი სანამ წაშლით, რადგან ფსევდონიმი და org-ის ჰოსტი ორი ფაქტია, რომელსაც მხარდაჭერა ითხოვს. ფსევდონიმის მოცილება შექცევადია, მაგრამ არასწორის მოცილება ინციდენტის შუაში მხოლოდ მეორე პრობლემას ამატებს.

სად უარყოფენ API მოთხოვნას რეალურად

თვალყური ადევნეთ ერთ მოთხოვნას თავიდან ბოლომდე და აღნიშნეთ, რომელი კომპონენტი პასუხობს. TLS შეცდომა სხვა პრობლემას ასახელებს, ვიდრე 403, რომელიც სხვა პრობლემას ასახელებს, ვიდრე დროის ამოწურვა, და დროის ამოწურვა ერთადერთია სამიდან, რომელიც გვირაბს პირველ ეჭვმიტანილად მიუთითებს. შეცდომის კლასის წაკითხვა შეტყობინებამდე ბევრ ვარაუდს ზოგავს. ჩაწერეთ კლასი სანამ რამეს ხელახლა გაუშვებთ.

წყარო მისამართის შეზღუდვები ის შემთხვევაა, რომელიც მომუშავე შესვლას და არამომუშავე მოთხოვნას იძლევა, რადგან ბრაუზერის ნაკადი და API გამოძახება შეიძლება სხვადასხვა მისამართით გავიდეს. ამის უფრო ფართო ნებადართულთა სიით გასწორება org-ის მფლობელის გადაწყვეტილებაა, არა კომფორტი, და ეს უნდა იყოს ყველაზე პატარა დიაპაზონი, რომელიც ჰოსტს ფარავს.

ჩაწერეთ წარუმატებელი ბრძანება, ფსევდონიმი, შესრულების ჰოსტი და დროის ნიშა, და ტოკენი დატოვეთ იმ ყველაფრის გარეთ, რასაც ბილეთში აკრავთ. ოთხსტრიქონიანი ეს შეჯამებაა ის, რაც org-ის მფლობელს სჭირდება საკუთარი მხარის შესამოწმებლად.

შეამოწმეთ ნაკადი იმ ჰოსტიდან, რომელიც გამოიყენებს მას

ტესტეთ იმ მანქანიდან, რომელიც სამუშაო დატვირთვას შეასრულებს. თქვენს ლეპტოპზე დადასტურებული შესვლა არაფერს ამბობს სხვა ქსელურ ზონაში მყოფ build აგენტზე, და განსხვავება ზუსტად ის არის, რასაც ეძებთ.

შემოწმებისთვის გამოიყენეთ უწყინარი ნებადართული წაკითხვა, და თუ ჩავარდა, პირველი შეცდომა შეინახეთ.

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

როცა შესვლა წარმატებულია, მაგრამ მოთხოვნა ჩავარდა, დარჩენილი კანდიდატები არიან DNS, მარშრუტიზაცია, TLS ჩარევა და org-ის მხრიდან კლიენტის პოლიტიკა, და თითოეულს თავისი მფლობელი ჰყავს. როცა თავად შესვლა ჩავარდა, ბრაუზერი და CLI, სავარაუდოდ, ერთ ჰოსტზე არ არიან, და გასწორება მათ შორის განლაგებას ეკუთვნის, არა გვირაბს. ავტომატიზაცია კიდევ ერთ წესს იღებს: უყურადღებო სამუშაოს სჭირდება დამტკიცებული სერტიფიკატზე დაფუძნებული შესვლა, რადგან მუშაზე კოპირებული ქეშირებული ინტერაქტიული სესია იდენტობის დიზაინი არ არის.