ورود به Salesforce CLI از طریق VPN: CLI، مرورگر و میزبان API

خطاهای ورود به Salesforce CLI به‌صورت یک مشکل گزارش می‌شوند و معمولاً سه‌اند. فرایند CLI جایی اجرا می‌شود، مرورگری که جریان وب را کامل می‌کند جایی اجرا می‌شود، و فراخوانی بعدی API جایی اجرا می‌شود، و این سه مکان لازم نیست مسیر، حل‌کننده یا فهرست مجاز مشترکی داشته باشند. مقایسه آن‌ها سریع‌ترین راه برای فهمیدن این است که تونل واقعاً کدام را مسدود می‌کند. هیچ‌چیز در خروجی ورود نمی‌گوید کدام یک از سه مورد شکست خورده است.

سه میزبان، یک داستان ورود

جریان ورود وب گام هویت را به مرورگر می‌سپارد، و آن مرورگر اغلب روی رایانه همراه شماست در حالی که CLI روی میزبان توسعه راه دور یا در یک کانتینر است. رایانه همراه مشتری VPN دارد، میزبان راه دور هر چیزی را دارد که تیم پلتفرم به آن داده است، و هیچ‌کدام از این دو چیدمان به‌طور خودکار دیگری را پوشش نمی‌دهد. نماد VPN در نوار وضعیت هیچ چیزی درباره میزبانی که هرگز مشتری را اجرا نکرده نمی‌گوید.

پس از ورود، CLI درخواست‌های API خود را از همان‌جایی که فرایند زندگی می‌کند می‌فرستد. این درخواست‌ها به DNS، مسیریابی، اعتماد TLS و مجوز مشتری در سمت سازمان نیاز دارند، که چهار بررسی جداگانه‌اند و هر یک می‌تواند به‌تنهایی شکست بخورد. مرورگری که زیبا وارد شده باشد هیچ چیزی درباره هیچ‌یک از آن‌ها به شما نمی‌گوید.

هر دو نیمه را در یک خط زمانی نگه دارید، اما آن‌ها را جداگانه امتیاز دهید. آنگاه یک تیکت می‌تواند بگوید کدام نیمه شکسته است بدون آنکه به بحثی درباره مالکیت تبدیل شود.

مدخل سازمان را از سازمان بگیرید، نه از حافظه

جریان وب یک URL نمونه می‌گیرد و نتیجه را زیر یک نام مستعار ذخیره می‌کند، و هر دو مقدار باید از مالک سازمان بیاید نه از تاریخچه ترمینال یک همکار. میزبان sandbox که از تیکت قدیمی کپی شده باشد علت شایعی برای ورودی است که علیه سازمان اشتباه احراز هویت می‌کند و سپس هر پرس‌وجو را شکست می‌دهد.

از شکلی که افزونه نصب‌شده مستند می‌کند استفاده کنید، با میزبان و نام مستعار تأییدشده خودتان. آن مستندات مرجع پرچم‌هایی است که بین 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 به احتمال زیاد روی یک میزبان نیستند، و اصلاح به چیدمان میان آن‌ها تعلق دارد نه به تونل. خودکارسازی یک قاعده دیگر می‌گیرد: کار بدون نظارت به یک ورود تأییدشده مبتنی بر گواهی نیاز دارد، زیرا نشست تعاملی کش‌شده‌ای که به یک کارگر کپی شده است طراحی هویت نیست.