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 সম্ভবত একই হোস্টে নয়, আর সমাধান টানেলের নয়, তাদের মধ্যকার ব্যবস্থার। অটোমেশনের জন্য আরও একটি নিয়ম: অ-পর্যবেক্ষিত কাজের জন্য অনুমোদিত সার্টিফিকেট-ভিত্তিক লগইন দরকার, কারণ ওয়ার্কারে কপি করা ক্যাশে করা ইন্টারঅ্যাকটিভ সেশন পরিচয়ের নকশা নয়।