VPN के ज़रिए Salesforce CLI लॉगिन: CLI, ब्राउज़र और API होस्ट

Salesforce CLI लॉगिन की विफलताएँ एक ही समस्या के रूप में दर्ज होती हैं और आम तौर पर तीन होती हैं। CLI प्रक्रिया कहीं चलती है, वेब फ़्लो पूरा करने वाला ब्राउज़र कहीं चलता है, और बाद की API कॉल कहीं चलती है, और इन तीन जगहों को एक ही रूट, रिज़ॉल्वर या अनुमति-सूची साझा करनी ज़रूरी नहीं है। इनकी तुलना करना यह पता लगाने का सबसे तेज़ तरीका है कि टनल असल में किसे रोक रही है। लॉगिन के आउटपुट में कुछ भी यह नहीं बताता कि तीनों में से कौन विफल हुआ।

तीन होस्ट, एक लॉगिन कहानी

वेब लॉगिन फ़्लो पहचान का चरण ब्राउज़र को सौंपता है, और वह ब्राउज़र अक्सर आपके लैपटॉप पर होता है जबकि CLI किसी दूरस्थ डेवलपमेंट होस्ट या कंटेनर में बैठा होता है। लैपटॉप के पास VPN क्लाइंट है, दूरस्थ होस्ट के पास वह है जो प्लेटफ़ॉर्म टीम ने दिया, और दोनों में से कोई भी व्यवस्था दूसरे को अपने आप नहीं ढकती। स्टेटस बार में VPN आइकन ऐसे होस्ट के बारे में कुछ नहीं कहता जिसने कभी क्लाइंट चलाया ही नहीं।

लॉगिन के बाद CLI अपनी API अनुरोध प्रक्रिया जहाँ रहती है वहीं से भेजता है। उन अनुरोधों को DNS, रूटिंग, TLS भरोसा और ऑर्ग की ओर क्लाइंट प्राधिकरण चाहिए, जो चार अलग जाँचें हैं और हर एक अकेले विफल हो सकती है। बहुत अच्छी तरह साइन इन करने वाला ब्राउज़र इनमें से किसी के बारे में कुछ नहीं बताता।

दोनों हिस्सों को एक टाइमलाइन पर रखें, पर उन्हें अलग-अलग आँकें। तब एक टिकट बता सकता है कि कौन-सा हिस्सा टूटा, बिना उसे मालिकाना की बहस में बदले।

ऑर्ग की प्रविष्टि ऑर्ग से लें, स्मृति से नहीं

वेब फ़्लो एक इंस्टेंस URL लेता है और परिणाम को एक उपनाम के तहत संग्रहीत करता है, और दोनों मान ऑर्ग मालिक से आने चाहिए, किसी सहकर्मी के टर्मिनल इतिहास से नहीं। पुराने टिकट से कॉपी किया गया सैंडबॉक्स होस्ट गलत ऑर्ग के सामने प्रमाणित होने और फिर हर क्वेरी विफल होने का आम कारण है।

इंस्टॉल किए गए प्लगइन जिस रूप का दस्तावेज़ीकरण करता है उसका उपयोग करें, अपने अनुमोदित होस्ट और उपनाम के साथ। वह दस्तावेज़ sfdx और वर्तमान CLI के बीच बदले फ़्लैग के लिए संदर्भ है।

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

ऊपर का होस्टनेम और उपनाम उदाहरण हैं, आपके कॉपी करने योग्य डिफ़ॉल्ट नहीं। सामान्य ब्राउज़र पहचान और MFA चरण पूरे करें, स्क्रिप्ट से उन्हें दरकिनार करने के बजाय, और प्रॉम्प्ट छोड़ने के लिए कभी भी शेल कमांड में पासवर्ड, सत्र पहचानकर्ता या प्रमाणक बीज न रखें।

कैश किया गया प्राधिकरण क्या साबित करता है

स्थानीय प्राधिकरण सूची में दिखने वाला उपनाम साबित करता है कि उस मशीन पर एक बार लॉगिन सफल हुआ था। सूची स्थानीय भंडारण से पढ़ी जाती है और यह पुष्टि करने के लिए ऑर्ग से संपर्क नहीं करती कि टोकन अभी भी काम करता है, इसलिए स्वस्थ दिखने वाली प्रविष्टि और अस्वीकृत API कॉल दोनों सच हो सकते हैं। कैश को बीते समय का रिकॉर्ड मानें, जीवंत कनेक्टिविटी परीक्षण नहीं। कैश जाँच सहायता प्रश्न का उत्तर देती है, पर कनेक्टिविटी जाँच कभी बंद नहीं करती।

यही भेद ब्राउज़र सत्र पर भी लागू होता है। जो टैब अभी भी ऑर्ग दिखा रहा है उसका मतलब यह नहीं कि CLI का संग्रहीत टोकन वर्तमान नीति से मेल खाता है, क्योंकि टोकन का जीवनकाल, IP प्रतिबंध और क्लाइंट-ऐप नियम API सीमा पर लागू होते हैं।

स्थानीय रिकॉर्ड को मिटाने से पहले पढ़ें, क्योंकि उपनाम और ऑर्ग होस्ट वे दो तथ्य हैं जो सहायता माँगेगी। उपनाम हटाना उलटा जा सकता है, पर घटना के बीच में गलत को हटाना सिर्फ़ दूसरी समस्या जोड़ता है।

API अनुरोध असल में कहाँ अस्वीकृत होता है

एक अनुरोध को शुरू से अंत तक ट्रेस करें और देखें कौन-सा घटक उत्तर देता है। TLS विफलता 403 से अलग समस्या बताती है, जो टाइमआउट से अलग समस्या बताती है, और तीनों में से केवल टाइमआउट ही टनल को पहला संदिग्ध ठहराता है। संदेश से पहले त्रुटि वर्ग पढ़ना बहुत अनुमान बचाता है। कुछ भी दोबारा चलाने से पहले वर्ग लिख लें।

स्रोत-पता प्रतिबंध वह स्थिति है जिसमें लॉगिन काम करता है और क्वेरी नहीं, क्योंकि ब्राउज़र फ़्लो और API कॉल अलग-अलग पतों से बाहर जा सकते हैं। इसे चौड़ी अनुमति-सूची से ठीक करना ऑर्ग मालिक का निर्णय है, सुविधा नहीं, और यह होस्ट को ढकने वाली सबसे छोटी श्रेणी होनी चाहिए।

विफल होने वाला कमांड, उपनाम, निष्पादन होस्ट और समय-चिह्न दर्ज करें, और टिकट में चिपकाए जाने वाली हर चीज़ से टोकन बाहर रखें। वही चार पंक्तियों का सार ऑर्ग मालिक को अपना पक्ष जाँचने के लिए चाहिए।

फ़्लो को उसी होस्ट से जाँचें जो इसका उपयोग करेगा

उसी मशीन से परीक्षण करें जो वर्कलोड चलाएगी। आपके लैपटॉप पर सत्यापित लॉगिन किसी दूसरे नेटवर्क ज़ोन के बिल्ड एजेंट के बारे में कुछ नहीं कहता, और अंतर ठीक वही है जो आप खोजना चाहते हैं।

जाँच के लिए हानिरहित अनुमत पठन का उपयोग करें, और विफल होने पर पहली त्रुटि रखें।

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

जब लॉगिन सफल हो पर क्वेरी विफल हो, तो शेष संभावित कारण DNS, रूटिंग, TLS अवरोधन और ऑर्ग की ओर क्लाइंट नीति हैं, और हर एक का अपना मालिक है। जब लॉगिन ख़ुद विफल हो, तो ब्राउज़र और CLI संभवतः एक ही होस्ट पर नहीं हैं, और सुधार टनल का नहीं, उनके बीच की व्यवस्था का है। ऑटोमेशन को एक और नियम मिलता है: बिना निगरानी वाले कार्य के लिए अनुमोदित प्रमाणपत्र-आधारित लॉगिन चाहिए, क्योंकि वर्कर पर कॉपी किया गया कैश सत्र पहचान का डिज़ाइन नहीं है।