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 ઇન્ટરફેસ અને તેના સમર્થિત ક્ષેત્રોને આવરે છે.