ഒന്നും മാറ്റാത്ത എഡിറ്റ് ചെയ്ത mac.py ആണ് സാധാരണ ആദ്യ ലക്ഷണം. ഡിസ്കിലുള്ള ഫയലല്ല Access Server പ്രവർത്തിപ്പിക്കുന്നത്; ഓതന്റിക്കേഷൻ സേവനം സ്ക്രിപ്റ്റ് സർവറിന്റെ കോൺഫിഗ് ഡാറ്റാബേസിൽ നിന്ന് ലോഡ് ചെയ്യുന്നു, ആ സംഭരിച്ച പകർപ്പാണ് ലോഗിൻ തീരുമാനിക്കുന്നത്. സംഭരിച്ച മൂല്യം മാറ്റിസ്ഥാപിക്കുന്നതുവരെ, ഓരോ പരിശോധനയും പഴയ സ്ക്രിപ്റ്റ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു.

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

ഫയൽ ഒരു സ്രോതസ്സാണ്, പ്രവർത്തിക്കുന്ന പകർപ്പല്ല

Access Server post-auth സ്ക്രിപ്റ്റ് auth.module.post_auth_script എന്ന കീയുടെ കീഴിൽ സൂക്ഷിക്കുന്നു. ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് നിങ്ങളുടെ പ്രവർത്തന പകർപ്പ് മാത്രം പുതുക്കുന്നു. ഡീമൺ സംഭരിച്ച മൂല്യം വായിക്കുന്നു, അതിനാൽ പഴയ എൻട്രി മായ്ച്ച് പുതിയ ഫയൽ അതിന്റെ സ്ഥാനത്ത് വയ്ക്കുന്നതുവരെ മാറ്റം അദൃശ്യമായി തുടരും. ആ സംഭരിച്ച മൂല്യമാണ് ഓതന്റിക്കേഷൻ സേവനം പരിശോധിക്കുന്ന ഒരേയൊരു പകർപ്പ്.

മാറ്റുന്നതിന് മുമ്പ് അത് വായിക്കുക. നിങ്ങൾ എഡിറ്റ് ചെയ്ത ഫയലുമായി ഇതിനകം പൊരുത്തപ്പെടുന്നുണ്ടെങ്കിൽ, പ്രശ്നം സംഭരണത്തിലല്ല, വ്യാപ്തിയുടെ ചോദ്യത്തിലേക്ക് പോകുക. പഴയ പതിപ്പ് കാണിക്കുന്നുണ്ടെങ്കിൽ, മാറ്റം സേവനത്തിൽ എത്തിയിട്ടില്ല.

./sacli -k auth.module.post_auth_script ConfigGet

സംഭരിച്ച പകർപ്പ് മാറ്റിസ്ഥാപിച്ച്, പിന്നീട് പ്രയോഗിക്കുക

എഴുതുന്നതിന് മുമ്പ് മായ്ക്കുന്നത് അലങ്കാരമല്ല. ConfigPut --value_file-നൊപ്പം ഒരു ഘട്ടത്തിൽ മൂല്യം മാറ്റിസ്ഥാപിക്കുന്നു, ആദ്യം ConfigDel ചെയ്യുന്നത് കാലഹരണപ്പെട്ടതോ കേടായതോ ആയ എൻട്രി അവശേഷിക്കുന്നത് അസാധ്യമാക്കുന്നു. തുടങ്ങുന്നതിന് മുമ്പ് പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റിന്റെ പകർപ്പ് സ്ക്രിപ്റ്റ് ഡയറക്ടറിക്ക് പുറത്ത് സൂക്ഷിക്കുക.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start മാറ്റിയ കോൺഫിഗ് ആന്തരിക സേവനങ്ങളിൽ പ്രയോഗിക്കുന്നു, അതാണ് പുതിയ സ്ക്രിപ്റ്റ് പ്രാബല്യത്തിൽ വരുത്തുന്നത്. ഇത് മുഴുവൻ യന്ത്രമോ ഡീമണോ പുനരാരംഭിക്കുന്നതിന് തുല്യമല്ല, നിങ്ങളുടെ മാറ്റത്തിന് അത് ആവശ്യമില്ലെങ്കിൽ അത് കൊണ്ട് മാറ്റിസ്ഥാപിക്കരുത്.

മൂല്യ ഫയലിന് കേവല പാത ഉപയോഗിക്കുക, root അത് വായിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുക. നിങ്ങളുടെ ഷെല്ലിൽ നിന്ന് പരിഹരിക്കപ്പെടുന്നതും എന്നാൽ സേവന അക്കൗണ്ടിൽ നിന്ന് അല്ലാത്തതുമായ പാത ConfigGet-ൽ ശരിയായി തോന്നുന്നതും ആദ്യ ലോഗിനിൽ പരാജയപ്പെടുന്നതുമായ സംഭരിച്ച മൂല്യം നൽകുന്നു. sacli start-ന് ശേഷം സംഭരിച്ച ഫലം ഒരിക്കൽ കൂടി പരിശോധിക്കുക, അതിന് മുമ്പല്ല.

മൊഡ്യൂൾ വ്യാപ്തി അല്ലെങ്കിൽ ഓരോ കണക്ഷനും: ചോദ്യം എവിടെയായിരിക്കണം

Python മൊഡ്യൂൾ തലത്തിലുള്ള പ്രസ്താവനകൾ സ്ക്രിപ്റ്റ് ലോഡ് ചെയ്യുമ്പോൾ ഒരിക്കൽ പ്രവർത്തിപ്പിക്കുന്നു. അതിനാൽ ഫയലിന്റെ മുകളിൽ എഴുതിയ ഡാറ്റാബേസ് ചോദ്യം ലോഡ് ചെയ്യുമ്പോൾ പട്ടിക വായിക്കുകയും ആ ഉത്തരം തുടർന്നുള്ള ഓരോ കണക്ഷനും സൂക്ഷിക്കുകയും ചെയ്യുന്നു. മാറ്റം ഒന്നും ചെയ്യാത്തതുപോലെ തോന്നുന്നതിന്റെ രണ്ടാമത്തെ കാരണം ഇതാണ്: കോഡ് പ്രവർത്തിക്കുന്നു, പക്ഷേ നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന സമയത്തല്ല.

ഓതന്റിക്കേഷനിൽ ഓരോന്നിനും പ്രവർത്തിക്കാൻ ചോദ്യം post_auth ഹാൻഡ്ലറിനുള്ളിൽ വയ്ക്കുക. രേഖപ്പെടുത്തിയ ഒപ്പം നിലനിർത്തുക, ഹാൻഡ്ലർ സ്വീകരിക്കുന്ന ഓതന്റിക്കേഷൻ ഫലം ക്രമീകരിക്കുക, വെറും സംഖ്യയ്ക്ക് പകരം അതേ വസ്തു തിരികെ നൽകുക.

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

രണ്ട് നിരസിക്കൽ പാതകൾ, ഒരു ഉടമ

തീരുമാനം പ്രാദേശിക ചോദ്യമാണെങ്കിൽ ഫലത്തിന്റെ ഉടമ Python ഹാൻഡ്ലറാണ്. ഇത് ബാഹ്യ HTTP പരിശോധനയാണെങ്കിൽ കമാൻഡിന്റെ എക്സിറ്റ് നില ഉത്തരം വഹിക്കട്ടെ: പൂജ്യമല്ലാത്ത കോഡിൽ പുറത്തുപോകുന്ന റാപ്പർ ലോഗിൻ നിരസിക്കുന്നു, അവസാന കമാൻഡിന്റെ നില വ്യക്തമായ exit ഇല്ലാതെ സ്ക്രിപ്റ്റിന്റെ നിലയാകുന്നു.

രഹസ്യം പ്രോസസ് പട്ടികയ്ക്ക് പുറത്ത് സൂക്ഷിക്കുക. root വായിക്കാവുന്ന ഫയലോ സേവനം കൈമാറുന്ന പരിസ്ഥിതി മൂല്യമോ, ഏത് പ്രാദേശിക ഉപയോക്താവിനും ps-ൽ നിന്ന് വായിക്കാവുന്ന ആർഗ്യുമെന്റിനെക്കാൾ സുരക്ഷിതമാണ്. വിളിക്കുന്നതിന് മുമ്പ് എൻഡ്പോയിന്റ് ഒരു വേരിയബിളിൽ ഉറപ്പിക്കുക, ടൈപ്പോ കോൺഫിഗറേഷൻ സമയത്ത് പരാജയപ്പെടാൻ, ആരുടെയെങ്കിലും ലോഗിൻ സമയത്തല്ല. ആ രഹസ്യം മറ്റേതെങ്കിലും ക്രെഡൻഷ്യലിനെപ്പോലെ കറക്കുക.

ഓരോ പരിശോധനയ്ക്കും ഒരു ഉടമ തിരഞ്ഞെടുക്കുക. ഡാറ്റാബേസിനോട് ചോദിക്കുകയും HTTP സേവനത്തെ വിളിക്കുകയും ചെയ്യുന്ന സ്ക്രിപ്റ്റിന്, രണ്ടും വിയോജിക്കുന്ന സാഹചര്യത്തിന് പ്രഖ്യാപിത മുൻഗണനാ നിയമം ആവശ്യമാണ്, അല്ലാത്തപക്ഷം ലോഗിലെ നിരസിക്കൽ കാരണം ഉപയോക്താവിനോട് പറഞ്ഞതുമായി പൊരുത്തപ്പെടില്ല.

അഡ്മിനിസ്ട്രേറ്ററെ പുറത്താക്കാതെ പ്രയോഗിക്കുക

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

രണ്ട് വ്യവസ്ഥകൾ കാത്തിരിക്കൂ എന്ന് പറയുന്നു: root ആയി മൂല്യ ഫയൽ വായിക്കാൻ കഴിയുന്നില്ല, അല്ലെങ്കിൽ അഡ്മിൻ ഇന്റർഫേസിലേക്ക് രണ്ടാമത്തെ വഴിയില്ല. രണ്ടും ചെറിയ മാറ്റത്തെ ലോക്കൗട്ടാക്കി മാറ്റുന്നു, ദിവസാവസാനം ഉത്പാദന സർവറിൽ പരീക്ഷിക്കാൻ യോഗ്യമായത് ഒന്നുമില്ല. Access Server രേഖകൾ post-auth ഇന്റർഫേസും അതിന്റെ പിന്തുണയ്ക്കുന്ന ഫീൽഡുകളും ഉൾക്കൊള്ളുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ