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 સંભવતઃ એક જ હોસ્ટ પર નથી, અને સુધારો ટનલનો નહીં, તેમની વચ્ચેની ગોઠવણનો છે. ઓટોમેશનને એક વધુ નિયમ મળે છે: બિન-દેખરેખવાળા કામને મંજૂર પ્રમાણપત્ર-આધારિત લોગિન જોઈએ, કારણ કે વર્કર પર કૉપિ કરેલું કૅશ સેશન ઓળખની રચના નથી.