VPN मार्फत Salesforce CLI लगइन: 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 सम्भवतः एउटै होस्टमा छैनन्, र सुधार टनेलको होइन, तिनीहरूबीचको व्यवस्थाको हो। स्वचालनले अर्को नियम पाउँछ: निगरानी नभएको कामलाई स्वीकृत प्रमाणपत्र-आधारित लगइन चाहिन्छ, किनकि वर्करमा प्रतिलिपि गरिएको क्यास गरिएको अन्तरक्रियात्मक सत्र पहिचानको डिजाइन होइन।