OpenVPN-ന്റെ auth-user-pass-verify സ്ക്രിപ്റ്റ്: എക്സിറ്റ് കോഡ് ശരിയാക്കുക

OpenVPN ഒരു ലോഗിൻ സ്ക്രിപ്റ്റിന്റെ കൃത്യം ഒരു ഔട്ട്പുട്ടിനെ അടിസ്ഥാനമാക്കി പ്രവർത്തിക്കുന്നു: എക്സിറ്റ് സ്റ്റാറ്റസ്. സ്ക്രിപ്റ്റ് ചെയ്യുന്ന ബാക്കിയെല്ലാം അലങ്കാരമാണ്. ഹുക്കിന് ശരിയായ വെരിഫയറിലെത്താം, പ്രതികരണം വിശകലനം ചെയ്യാം, സൗഹൃദപരമായ ഒരു വരി പ്രിന്റ് ചെയ്യാം, എന്നാൽ രചയിതാവിന്റെ ഉദ്ദേശ്യത്തിന് വിപരീതമായ അർത്ഥമുള്ള സ്റ്റാറ്റസ് തിരികെ നൽകാം. ആദ്യം കരാർ വായിച്ച് അതിനു ചുറ്റും അഡാപ്റ്റർ എഴുതുക, എന്നാൽ ആ മുഴുവൻ ബഗ് വിഭാഗവും അപ്രത്യക്ഷമാകും.

കരാർ ചെറുതാണ്: സമർപ്പിച്ച അക്കൗണ്ട് തിരിച്ചറിയുക, അംഗീകൃത വെരിഫയറിനോട് ഉദ്ദേശിച്ച ചോദ്യം ചോദിക്കുക, ആ അഭ്യർത്ഥനയ്ക്ക് ആ വെരിഫയറിന്റെ രേഖപ്പെടുത്തിയ പോസിറ്റീവ് ഫലം മാത്രം സ്വീകരിക്കുക. ബാക്കിയെല്ലാം അടിസ്ഥാന സൗകര്യമാണ്.

ഹുക്കിന് തിരികെ നൽകാവുന്ന മൂന്ന് സ്റ്റാറ്റസുകൾ

auth-user-pass-verify എന്നതിന് OpenVPN 2.6 കൈപ്പുസ്തകം എക്സിറ്റ് കോഡ് 0 സ്വീകരണമായും, 1 നിരസിക്കലായും, 2 മാറ്റിവെച്ച പ്രാമാണീകരണമായും നിർവചിക്കുന്നു. സെർവർ മനസ്സിലാക്കുന്ന ഏക മൂന്ന് ഉത്തരങ്ങൾ ഇവയാണ്, ഓരോന്നിനും കണക്ഷനിൽ വ്യത്യസ്ത ഫലമുണ്ട്. തന്റെ അവസാന കമാന്റിന്റെ സ്റ്റാറ്റസോടെ പുറത്തുപോകുന്ന സ്ക്രിപ്റ്റ് യഥാർത്ഥത്തിൽ ഒരു ലോഗ് കോളിനോ ക്ലീനപ്പ് ഘട്ടത്തിനോ വോട്ട് ചെയ്യാൻ അനുവദിച്ചിരിക്കുന്നു. ഓരോ ശാഖയിലും സ്റ്റാറ്റസ് വ്യക്തമായി എഴുതുക, വെരിഫയറിൽ എത്താത്ത ശാഖകളും ഉൾപ്പെടെ.

HTTP വിജയവും പ്രാമാണീകരണ വിജയവും വെവ്വേറെ പാളികളാണ്, അവ കൂട്ടിക്കലർത്തുന്നതാണ് ഈ ഹുക്ക് തെറ്റാകുന്ന ഏറ്റവും സാധാരണ വഴി. 202 പ്രതികരണം അർത്ഥമാക്കുന്നത് അഭ്യർത്ഥന പ്രോസസ്സിംഗിനായി സ്വീകരിച്ചു എന്നാണ്, പാസ്വേഡ് സ്ഥിരീകരിച്ചു എന്നല്ല. നിങ്ങൾക്ക് നൽകിയ API കരാറിൽ നിന്ന് പ്രതീക്ഷിത സ്റ്റാറ്റസും പ്രതികരണത്തിന്റെ രൂപവും അന്തിമ വിധിയും നിർവചിക്കുക, സാധ്യതയുള്ളതായി തോന്നുന്നതിനാൽ ഒരു ഫീൽഡ് പേരും കെട്ടിച്ചമയ്ക്കരുത്.

ഉത്തരം ശരിക്കും പിന്നീട് വന്നാൽ, അതാണ് മാറ്റിവെച്ച പാത, അത് അങ്ങനെ തന്നെ നിർമ്മിക്കണം. ഒരിക്കലും പൂർത്തിയാകാത്ത മാറ്റിവെച്ച ശ്രമം സമയപരിധി കഴിയുന്നതുവരെ വിഭവങ്ങൾ പിടിച്ചുവയ്ക്കുന്നു.

ക്രെഡൻഷ്യൽ ഫയൽ എഴുതിയിരിക്കുന്നത് പോലെ തന്നെ വായിക്കുക

രേഖപ്പെടുത്തിയ ഫയൽ വഴിയുള്ള രീതിയിൽ, സെർവർ ഉപയോക്തൃനാമവും പാസ്വേഡും ഒരു താൽക്കാലിക ഫയലിന്റെ ആദ്യ രണ്ട് വരികളായി എഴുതുന്നു, ആ പാത സ്ക്രിപ്റ്റിന് നൽകുന്നു, സ്ക്രിപ്റ്റ് മടങ്ങുമ്പോൾ ഫയൽ നീക്കം ചെയ്യുന്നു. ആ രണ്ട് വരികളും ഡാറ്റയായി വായിക്കുക: ഫയൽ ഒരിക്കലും source ചെയ്യരുത്, ഒരിക്കലും മൂല്യനിർണ്ണയം ചെയ്യരുത്, പ്രോസസ് പട്ടിക കാണാൻ കഴിയുന്ന ഒരു കമാന്റ് ലൈനിൽ അതിന്റെ ഉള്ളടക്കം ഒരിക്കലും ഒട്ടിക്കരുത്. പാസ്വേഡ് ബൈറ്റ് തോറും സൂക്ഷിക്കുക, കാരണം ഉപയോക്തൃനാമം പോലെ അത് സാധാരണവൽക്കരിക്കുന്നത് ക്രെഡൻഷ്യൽ നിശബ്ദമായി മാറ്റുന്നു. ആ താൽക്കാലിക ഫയലിന്റെ ഡയറക്ടറി ഒരു വിന്യാസ തീരുമാനമാണ്, അതിനാൽ അത് നിലവിലുണ്ടെന്നും ഹോസ്റ്റിലെ എല്ലാവർക്കും വായിക്കാനാവില്ലെന്നും ഉറപ്പാക്കുക.

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

വർഗ്ഗീകരിക്കാനാവാത്ത ഉത്തരത്തിന്റെ അർത്ഥം തീരുമാനിക്കുക

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

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

സെർവർ കോൺഫിഗറേഷനും ഇവിടെ പ്രധാനമാണ്: ഉപയോക്താവ് നിർവചിച്ച സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ ആവശ്യമായ സുരക്ഷാ നിലയിൽ അനുവദിക്കുമ്പോൾ മാത്രമേ പരിഗണിക്കൂ, ആ ക്രമീകരണം ഉയർത്തേണ്ട ഡിഫോൾട്ടല്ല, മനഃപൂർവമുള്ള തിരഞ്ഞെടുപ്പാണ്.

വിധി പരിശോധിക്കുക, പ്രിന്റ് ചെയ്ത വരിയല്ല

എക്സിറ്റ് സ്റ്റാറ്റസ് നേരിട്ട് പരിശോധിക്കുന്ന ഒരു പരീക്ഷണം നിർമ്മിക്കുക. ഒരു മാതൃകാ ക്രെഡൻഷ്യൽ ഫയൽ എഴുതുക, അറിയപ്പെടുന്ന നല്ലതും അറിയപ്പെടുന്ന മോശവുമായ അക്കൗണ്ടുകളുമായി അതിനെതിരെ ഹുക്ക് പ്രവർത്തിപ്പിക്കുക, സ്ക്രിപ്റ്റ് പ്രിന്റ് ചെയ്യുന്ന പാഠത്തിന് പകരം ഷെൽ റിപ്പോർട്ട് ചെയ്യുന്ന സ്റ്റാറ്റസ് വായിക്കുക. ആ ഒരു പരിശോധന ക്ലയന്റ് കണക്ട് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ മിക്ക കരാർ ബഗുകളും പിടിക്കുന്നു.

തുടർന്ന് അതേ കേസുകൾ ഒരു യഥാർത്ഥ ക്ലയന്റിലൂടെ ഉത്പാദനേതര ശ്രോതാവിനെതിരെ പ്രവർത്തിപ്പിച്ച് സെർവർ എന്ത് രേഖപ്പെടുത്തി എന്ന് സ്ഥിരീകരിക്കുക: സ്വീകരിച്ചു, നിരസിച്ചു അല്ലെങ്കിൽ മാറ്റിവെച്ചു. നിഷ്ക്രിയ അക്കൗണ്ട്, തെറ്റായ പാസ്വേഡ്, വികലമായ വെരിഫയർ പ്രതികരണം, സമയപരിധി, എത്തിച്ചേരാനാവാത്ത വെരിഫയർ എന്നിവ ഉൾപ്പെടുത്തുക. ഏതെങ്കിലും കേസ് നിങ്ങൾക്ക് പേര് നൽകാനാവാത്ത ഒരു അവസ്ഥയിൽ എത്തിയാൽ, അഡാപ്റ്റർ പൂർത്തിയായിട്ടില്ല.

വെരിഫയർ ഫലത്തിൽ നിന്ന് എക്സിറ്റ് സ്റ്റാറ്റസിലേക്കുള്ള മാപ്പിംഗ് റിപ്പോസിറ്ററിയിൽ സ്ക്രിപ്റ്റിന് അരികിൽ സൂക്ഷിക്കുക, അടുത്ത എഞ്ചിനീയർക്ക് കോഡ് റിവേഴ്സ് എഞ്ചിനീയറിംഗ് ചെയ്യാതെ കരാർ വായിക്കാൻ കഴിയേണ്ടതിന്.