Access Server उस post_auth स्क्रिप्ट को अनदेखा करता है जिसे आपने डिस्क पर संपादित किया

संपादित 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 इंटरफ़ेस और उसके समर्थित फ़ील्ड को कवर करते हैं।