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 ممکنہ طور پر ایک ہی میزبان پر نہیں، اور درستی سرنگ کی نہیں، ان کے درمیان انتظام کی ہے۔ آٹومیشن کو ایک اور قاعدہ ملتا ہے: بغیر نگرانی والے کام کے لیے منظور شدہ سرٹیفکیٹ پر مبنی لاگ اِن درکار ہے، کیونکہ ورکر پر کاپی کیا گیا کیش شدہ انٹرایکٹو سیشن شناخت کی ڈیزائن نہیں ہے۔