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 ഉടമയ്ക്ക് തന്റെ വശം പരിശോധിക്കാൻ വേണ്ടത്.

ഉപയോഗിക്കാൻ പോകുന്ന ഹോസ്റ്റിൽ നിന്നുതന്നെ ഫ്ലോ പരിശോധിക്കുക

വർക്ക്ലോഡ് പ്രവർത്തിപ്പിക്കാൻ പോകുന്ന മെഷീനിൽ നിന്ന് പരീക്ഷിക്കുക. നിങ്ങളുടെ ലാപ്ടോപ്പിൽ സ്ഥിരീകരിച്ച ലോഗിൻ മറ്റൊരു നെറ്റ്വർക്ക് മേഖലയിലെ build ഏജന്റിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ആ വ്യത്യാസമാണ് നിങ്ങൾ കണ്ടെത്താൻ ശ്രമിക്കുന്നത്.

പരിശോധനയ്ക്ക് നിരുപദ്രവകരമായ അനുവദിച്ച വായന ഉപയോഗിക്കുക, പരാജയപ്പെട്ടാൽ ആദ്യ പിശക് സൂക്ഷിക്കുക.

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-യും ഒരേ ഹോസ്റ്റിൽ ആയിരിക്കാൻ സാധ്യതയില്ല, പരിഹാരം ടണലിന്റേതല്ല, അവയ്ക്കിടയിലുള്ള ക്രമീകരണത്തിന്റേതാണ്. ഓട്ടോമേഷന് ഒരു നിയമം കൂടി ലഭിക്കുന്നു: മനുഷ്യനിരീക്ഷണമില്ലാത്ത ജോലിക്ക് അംഗീകൃത സർട്ടിഫിക്കറ്റ് അടിസ്ഥാനമാക്കിയ ലോഗിൻ വേണം, കാരണം വർക്കറിലേക്ക് പകർത്തിയ കാഷ് ചെയ്ത ഇന്ററാക്ടീവ് സെഷൻ ഐഡന്റിറ്റി ഡിസൈൻ അല്ല.