പൊതു ഫോം സമർപ്പണങ്ങൾ സ്വകാര്യ നെറ്റ്വർക്കിലേക്ക് ഇറക്കുമതി ചെയ്യുന്ന വിധം

സ്വകാര്യ നെറ്റ്വർക്കുമായി ഒരിക്കലും സംസാരിക്കാത്ത ഒരു പൊതു ഫോം പോലും സ്വകാര്യ നെറ്റ്വർക്ക് വിലയിരുത്തേണ്ട ഡാറ്റ ഉത്പാദിപ്പിക്കുന്നു. ടണൽ ആര് ആരെ വിളിക്കുന്നു എന്നത് മാത്രം മാറ്റുന്നു. ഡൗൺലോഡിന് ശേഷമുള്ളതെല്ലാം ഒരു ഇറക്കുമതി തീരുമാനമാണ്, അത് സ്വകാര്യ വശത്തിനാണ്. ഈ വിശദീകരണം ഒരു സമർപ്പണത്തെ ബ്രൗസറിൽ നിന്ന് കമ്മിറ്റ് ചെയ്ത ആന്തരിക രേഖ വരെ പിന്തുടരുന്നു.

സമർപ്പണം എത്തുന്നിടത്ത് നിന്ന് ആരംഭിക്കുക

ബ്രൗസർ ഒരു പൊതു എൻഡ്പോയിന്റിലേക്ക് അയയ്ക്കുന്നു, അത് നിയന്ത്രിത സ്വീകരണ സംഭരണിയിൽ ഒരു വരി എഴുതുകയും സ്ഥിരീകരണത്തിൽ കൂടുതലൊന്നും തിരികെ നൽകുകയും ചെയ്യുന്നു. ആ സംഭരണിയാണ് കൈമാറ്റ പോയിന്റ്, പൊതു തലത്തിന് എഴുതാൻ കഴിയുന്ന ഒരേയൊരു കാര്യം അതായിരിക്കണം. അസംസ്കൃത ഡാറ്റ അവിടെ മാറ്റമില്ലാതെ, അത് എത്തിയ സമയവും സ്ഥിരമായ രേഖ ഐഡന്റിഫയറും സഹിതം സൂക്ഷിക്കുക.

തുടർന്ന് സ്വകാര്യ തൊഴിലാളി ടണലിലൂടെ കാത്തിരിക്കുന്ന വരികൾ വലിച്ചെടുത്ത് ഓരോന്നിനും എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കുന്നു. അത് സ്വന്തം ഐഡന്റിറ്റിയിൽ പ്രവർത്തിക്കുന്നു, അതാണ് അടുത്ത വിഭാഗത്തിന്റെ വിഷയം.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

ഇറക്കുമതിക്കാരന് ആവശ്യമായ അധികാരം മാത്രം നൽകുക

പൊതു വെബ് പ്രക്രിയയും ആന്തരിക ആപ്ലിക്കേഷനിൽ എഴുതുന്ന ഐഡന്റിറ്റിയും രണ്ട് വ്യത്യസ്ത പ്രിൻസിപ്പലുകളായിരിക്കണം. ഫോം ഡാറ്റ എത്തിക്കേണ്ടതുണ്ട് എന്ന കാരണത്താൽ മാത്രം ഒരു പൊതു സെർവറിന് ആന്തരിക ഭരണം ആവശ്യമില്ല, ഇരു വശങ്ങൾക്കും ഒരു പങ്കിട്ട അക്കൗണ്ട് ഏതൊരു വെബ് ബഗിനെയും ആന്തരിക എഴുത്താക്കി മാറ്റുന്നു. തൊഴിലാളിക്ക് സ്വന്തം ആധികാരികത നൽകുക, അതിനെ ഒരു ഇറക്കുമതി പ്രവർത്തനത്തിലേക്ക് പരിമിതപ്പെടുത്തുക, ഓരോ ഇറക്കുമതിയും ഏത് പ്രിൻസിപ്പൽ നിർവഹിച്ചു എന്ന് രേഖപ്പെടുത്തുക. ആ വേർതിരിവാണ് ടണൽ അതിർത്തിയെ അലങ്കാരമല്ലാതെ അർത്ഥവത്താക്കുന്നത്.

തൊഴിലാളിക്ക് ഏത് ഉറവിടത്തിൽ നിന്ന് വായിക്കാം എന്നതും പരിമിതപ്പെടുത്തുക. നടപ്പാക്കൽ ഒരു ക്യൂ അല്ലെങ്കിൽ കൈമാറ്റ സേവനം ഉപയോഗിക്കുന്നുവെങ്കിൽ, ആ സേവനം സ്വന്തം പ്രാമാണീകരണവും പ്രവേശന നയവും നിലനിർത്തുന്നു, കാരണം VPN പേലോഡിനുള്ളിൽ ഒന്നും പ്രാമാണീകരിക്കുന്നില്ല.

ഹ്രസ്വകാല ഫങ്ക്ഷനും അതേ അവലോകനത്തിൽ നിന്ന് ഒഴിവല്ല. അത് പ്രവർത്തിക്കുന്ന സമയത്ത് അതിന്റെ നെറ്റ്വർക്ക് സ്ഥാനവും ആധികാരികതകളും ഇപ്പോഴും അധികാരം നൽകുന്നു, ചെറിയ ആയുസ്സ് വിൻഡോ ചുരുക്കുന്നു മാത്രം. ഐഡന്റിറ്റിക്ക് ഏത് പ്രവർത്തനങ്ങൾ ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നതിന് പകരമല്ല ആയുസ്സ്.

ആന്തരികമായി എന്തെങ്കിലും മാറുന്നതിന് മുൻപ് സാധുത പരിശോധിക്കുക

പൊതു ഫോം ഫീൽഡുകൾ വിപരീതം തെളിയിക്കുന്നത് വരെ ആക്രമണകാരി നിയന്ത്രിക്കുന്ന വാചകമാണ്, അതുകൊണ്ട് തന്നെ OWASP-ന്റെ ഇൻപുട്ട് സാധുത പരിശോധനാ മാർഗനിർദേശം ബാക്കെൻഡ് ഫീഡുകളെ വിശ്വാസയോഗ്യമല്ലാത്ത ഉറവിടങ്ങളിൽ ഉൾപ്പെടുത്തുന്നു. എൻക്രിപ്റ്റ് ചെയ്ത കൈമാറ്റം ബൈറ്റുകൾ കേടുകൂടാതെ എത്തി എന്നാണ് പറയുന്നത്, അവ അനുവദനീയമായ ഒരു അഭ്യർത്ഥന വിവരിക്കുന്നു എന്നല്ല. ഏതെങ്കിലും പ്രത്യേകാവകാശ ഘട്ടത്തിന് മുൻപ് പാഴ്സ് ചെയ്ത് സാധുത പരിശോധിക്കുക, അപ്പോൾ മോശം വരി പ്രവർത്തിക്കാൻ കഴിയുന്ന കോഡ് പാതയിൽ എത്തില്ല.

അനുവദനീയമായ ഫീൽഡുകൾ, അവയുടെ ഫോർമാറ്റുകൾ, വലിപ്പങ്ങൾ, പാലിക്കേണ്ട ബിസിനസ് നിയമങ്ങൾ എന്നിവ നിർവചിക്കുക. ഒരു തീയതി ശരിയായി രൂപപ്പെട്ടതാകാം, എന്നിട്ടും അഭ്യർത്ഥിച്ച പ്രവർത്തനത്തിന് തെറ്റായിരിക്കാം, ആന്തരിക അക്കൗണ്ടോ അംഗീകാര നിലയോ പേരിടുന്ന പേലോഡിന് അവയൊന്നും സ്വയം നൽകാൻ കഴിയരുത്.

നിരസിച്ച വരികൾ തിരുത്തൽ ഊഹിക്കുന്നതിന് പകരം ഒരു അവലോകന ഫലത്തിലേക്ക് അയയ്ക്കുക, അല്ലെങ്കിൽ അവ ഷെല്ലിലേക്കോ അസംസ്കൃത ഡാറ്റാബേസ് ഇന്റർഫേസിലേക്കോ കൈമാറരുത്. രേഖ ഐഡന്റിഫയറും പരാജയപ്പെട്ട നിയമവും രേഖപ്പെടുത്തുക, അപേക്ഷകൻ ടൈപ്പ് ചെയ്ത ഓരോ ഫീൽഡും അല്ല.

ഒരു പ്രവർത്തനത്തിൽ വീണ്ടും ശ്രമിക്കാനുള്ള പോയിന്റ് ഉണ്ടാക്കുക

ആദ്യ സ്ഥിരീകരണം നഷ്ടപ്പെട്ടതിനാൽ submission-1042 രേഖ രണ്ടുതവണ വലിച്ചെടുക്കപ്പെട്ടാൽ, ഉറവിട രേഖയും അതിന്റെ കമ്മിറ്റ് ചെയ്ത ഫലവും തിരിച്ചറിയാൻ തൊഴിലാളിക്ക് ഒരു സ്ഥിരമായ വഴി വേണം. ജോലി ഒരിക്കൽ പ്രവർത്തിപ്പിക്കുന്ന ഒരു ഷെഡ്യൂൾ ഓരോ വരിയും ഒരിക്കൽ പ്രയോഗിച്ചു എന്ന് തെളിയിക്കുന്നില്ല. ഇരട്ട ഡെലിവറി സാധാരണമാണ്, അതിനാൽ രൂപകൽപ്പന അതിനെ ഉൾക്കൊള്ളണം.

ആന്തരിക ആപ്ലിക്കേഷന്റെ സ്വന്തം ഇടപാടും ഇരട്ട പ്രവർത്തന സംവിധാനവും ഉപയോഗിക്കുക, ഉറവിട ഐഡന്റിഫയർ, ഫലം, സ്ഥിരീകരണം എന്നിവ ഒരു സ്ഥിരതയുള്ള ക്രമത്തിൽ സൂക്ഷിക്കുക. ഉദ്ദേശിച്ച പ്രവർത്തനം കമ്മിറ്റ് ചെയ്തതിനോ സ്ഥിരമായി അനുവദിച്ചതിനോ ശേഷം മാത്രം സ്ഥിരീകരിക്കുക, ബൈറ്റുകൾ ഡൗൺലോഡ് ചെയ്തു എന്ന കാരണത്താൽ സ്വീകരണ വരി ഒരിക്കലും ഇല്ലാതാക്കരുത്.

തുടർന്ന് മൂന്ന് ഫിക്സ്ചറുകൾ കൊണ്ട് അത് തെളിയിക്കുക: സാധുവായ ഒരു വരി, തെറ്റായി രൂപപ്പെട്ട ഒരു വരി, അതേ നിയന്ത്രിത ഉറവിട ഐഡന്റിഫയർ രണ്ടുതവണ എത്തിച്ചത്. ഓരോന്നും തൊഴിലാളി ഉപയോഗിക്കുന്ന അതേ എൻഡ്പോയിന്റിലൂടെ കടന്നുപോകുന്നു.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

ആദ്യ രണ്ട് വരികൾ വ്യത്യസ്ത ആന്തരിക അവസ്ഥകളിൽ അവസാനിക്കണം, മൂന്നാമത്തേത് രണ്ടാമത്തേത് സൃഷ്ടിക്കുന്നതിന് പകരം ആ ഉറവിട രേഖയ്ക്ക് ഇതിനകം കമ്മിറ്റ് ചെയ്ത ഐഡന്റിഫയർ തിരികെ നൽകണം. മറ്റെന്തെങ്കിലും ഫലം എന്നാൽ ഇറക്കുമതി ഇപ്പോഴും ആവർത്തിക്കാനാകുന്നില്ല എന്നാണ്.