เข้าสู่ระบบ Salesforce CLI ผ่าน VPN: CLI, เบราว์เซอร์ และโฮสต์ API

ความล้มเหลวในการเข้าสู่ระบบ Salesforce CLI มักถูกรายงานเป็นปัญหาเดียว แต่จริง ๆ แล้วมักมีสามปัญหา กระบวนการ CLI ทำงานอยู่ที่หนึ่ง เบราว์เซอร์ที่ทำขั้นตอนเว็บให้เสร็จทำงานอีกที่หนึ่ง และการเรียก API ในภายหลังก็ทำงานอีกที่หนึ่ง สามจุดนี้ไม่จำเป็นต้องใช้เส้นทาง ตัวแปลงชื่อ หรือรายการที่อนุญาตร่วมกัน การเปรียบเทียบทั้งสามจุดเป็นวิธีที่เร็วที่สุดในการรู้ว่าอุโมงค์กำลังบล็อกจุดใดจริง ๆ ไม่มีอะไรในผลลัพธ์การเข้าสู่ระบบที่บอกว่าจุดใดในสามจุดล้มเหลว

สามโฮสต์ เรื่องราวการเข้าสู่ระบบเดียว

ขั้นตอนการเข้าสู่ระบบผ่านเว็บมอบหมายขั้นตอนยืนยันตัวตนให้เบราว์เซอร์ และเบราว์เซอร์นั้นมักอยู่ในแล็ปท็อปของคุณ ขณะที่ CLI อยู่บนโฮสต์พัฒนาระยะไกลหรือในคอนเทนเนอร์ แล็ปท็อปมีไคลเอนต์ VPN โฮสต์ระยะไกลมีสิ่งที่ทีมแพลตฟอร์มมอบให้ และไม่มีรูปแบบใดครอบคลุมอีกรูปแบบโดยอัตโนมัติ ไอคอน VPN ในแถบสถานะไม่ได้บอกอะไรเกี่ยวกับโฮสต์ที่ไม่เคยรันไคลเอนต์เลย

หลังเข้าสู่ระบบ CLI จะส่งคำขอ API ของตัวเองจากที่ที่กระบวนการอาศัยอยู่ คำขอเหล่านั้นต้องใช้ DNS การกำหนดเส้นทาง ความเชื่อถือ TLS และการอนุญาตไคลเอนต์จากฝั่ง org ซึ่งเป็นการตรวจสอบแยกกันสี่อย่างและแต่ละอย่างล้มเหลวได้เอง เบราว์เซอร์ที่เข้าสู่ระบบได้สวยงามไม่ได้บอกอะไรเกี่ยวกับสิ่งเหล่านี้เลย

เก็บทั้งสองครึ่งไว้บนเส้นเวลาเดียวกัน แต่ให้คะแนนแยกกัน จากนั้นตั๋วใบเดียวก็บอกได้ว่าครึ่งไหนพัง โดยไม่ต้องกลายเป็นข้อโต้แย้งเรื่องความเป็นเจ้าของ

เอารายการ org จาก org ไม่ใช่จากความจำ

ขั้นตอนเว็บรับ URL ของอินสแตนซ์และเก็บผลลัพธ์ไว้ใต้นามแฝง และทั้งสองค่าควรมาจากเจ้าของ org ไม่ใช่จากประวัติเทอร์มินัลของเพื่อนร่วมงาน โฮสต์แซนด์บ็อกซ์ที่คัดลอกจากตั๋วเก่าเป็นสาเหตุทั่วไปของการเข้าสู่ระบบที่ยืนยันตัวตนกับ 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 ตามปกติให้ครบ แทนที่จะเขียนสคริปต์ข้ามขั้นตอนเหล่านั้นและอย่าใส่รหัสผ่าน ตัวระบุเซสชัน หรือเมล็ดของแอปยืนยันตัวตนลงในคำสั่งเชลล์เพื่อข้ามการถามเลย

สิ่งที่การอนุญาตที่แคชไว้พิสูจน์

นามแฝงที่ปรากฏในรายการอนุญาตภายในเครื่องพิสูจน์ว่าการเข้าสู่ระบบเคยสำเร็จบนเครื่องนั้น รายการนี้อ่านจากที่จัดเก็บภายในเครื่องและไม่ได้ติดต่อ org เพื่อยืนยันว่าโทเคนยังใช้งานได้ ดังนั้นรายการที่ดูสมบูรณ์และการเรียก API ที่ถูกปฏิเสธจึงเป็นจริงพร้อมกันได้ ให้ถือว่าแคชเป็นบันทึกของอดีต ไม่ใช่การทดสอบการเชื่อมต่อแบบสด การตรวจสอบแคชตอบคำถามฝ่ายสนับสนุนได้ แต่ไม่เคยปิดการสอบสวนเรื่องการเชื่อมต่อ

ความแตกต่างเดียวกันใช้กับเซสชันของเบราว์เซอร์ แท็บที่ยังแสดง org ไม่ได้หมายความว่าโทเคนที่เก็บไว้ของ CLI ตรงกับนโยบายปัจจุบัน เพราะอายุโทเคน ข้อจำกัด IP และกฎของแอปไคลเอนต์ถูกบังคับใช้ที่ขอบเขต API

อ่านบันทึกภายในเครื่องก่อนลบ เพราะนามแฝงและโฮสต์ org คือสองข้อเท็จจริงที่ฝ่ายสนับสนุนจะถามถึง การลบนามแฝงย้อนกลับได้ แต่การลบอันผิดระหว่างเหตุการณ์กลับเพิ่มปัญหาที่สอง

การเรียก API ถูกปฏิเสธที่จุดใดจริง ๆ

ติดตามคำขอหนึ่งรายการตั้งแต่ต้นจนจบและบันทึกว่าองค์ประกอบใดตอบกลับ ความล้มเหลวของ TLS ระบุปัญหาที่ต่างจาก 403 ซึ่งระบุปัญหาที่ต่างจากหมดเวลา และหมดเวลาเป็นหนึ่งเดียวในสามอย่างที่ชี้ไปที่อุโมงค์เป็นผู้ต้องสงสัยรายแรก การอ่านคลาสของข้อผิดพลาดก่อนอ่านข้อความช่วยประหยัดการเดาได้มาก จดคลาสไว้ก่อนจะรันอะไรใหม่

ข้อจำกัดที่อยู่ต้นทางคือกรณีที่ทำให้เข้าสู่ระบบได้แต่ค้นหาไม่ได้ เพราะขั้นตอนของเบราว์เซอร์และการเรียก API อาจออกผ่านที่อยู่ที่ต่างกัน การแก้ด้วยรายการที่อนุญาตกว้างขึ้นเป็นการตัดสินใจของเจ้าของ org ไม่ใช่ความสะดวก และควรเป็นช่วงที่เล็กที่สุดที่ครอบคลุมโฮสต์

บันทึกคำสั่งที่ล้มเหลว นามแฝง โฮสต์ที่ใช้รัน และตราเวลา และเก็บโทเคนไว้นอกทุกสิ่งที่คุณวางในตั๋ว สรุปสี่บรรทัดนั้นคือสิ่งที่เจ้าของ org ต้องใช้เพื่อตรวจฝั่งของตน

ตรวจสอบขั้นตอนจากโฮสต์ที่จะใช้งานจริง

ทดสอบจากเครื่องที่จะรันงานจริง การเข้าสู่ระบบที่ตรวจสอบบนแล็ปท็อปของคุณไม่ได้บอกอะไรเกี่ยวกับเอเจนต์บิลด์ในโซนเครือข่ายอื่น และความต่างนั้นคือสิ่งที่คุณกำลังตามหาพอดี

ใช้การอ่านที่ได้รับอนุญาตและไม่เป็นอันตรายสำหรับการตรวจสอบ และถ้าล้มเหลวให้เก็บข้อผิดพลาดแรกไว้

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 น่าจะไม่ได้อยู่บนโฮสต์เดียวกัน และการแก้ไขเป็นเรื่องของรูปแบบระหว่างทั้งสอง ไม่ใช่ของอุโมงค์ ระบบอัตโนมัติได้กฎเพิ่มอีกข้อ งานที่ไม่มีการดูแลต้องใช้การเข้าสู่ระบบที่อนุมัติและอิงใบรับรอง เพราะเซสชันโต้ตอบที่แคชไว้และคัดลอกไปยังเวิร์กเกอร์ไม่ใช่การออกแบบอัตลักษณ์