OpenVPN ની auth-user-pass-verify સ્ક્રિપ્ટ: એક્ઝિટ કોડ બરાબર મેળવો
હૂકની એક્ઝિટ સ્થિતિ જ નિર્ણય છે, તેની લોગ લાઇન નહીં. ચકાસણીકર્તાના પરિણામોને 0, 1 અથવા મુલતવી પર મેપ કરો, ક્રેડેન્શિયલ ફાઇલને ડેટા તરીકે વાંચો અને ભૂલ પર બંધ રહો.
OpenVPN લોગિન સ્ક્રિપ્ટના બરાબર એક આઉટપુટ પર કાર્ય કરે છે: એક્ઝિટ સ્થિતિ. સ્ક્રિપ્ટ બાકી જે કંઈ કરે છે તે શણગાર છે. હૂક યોગ્ય ચકાસણીકર્તા સુધી પહોંચી શકે, પ્રતિસાદનું વિશ્લેષણ કરી શકે અને મૈત્રીપૂર્ણ લાઇન છાપી શકે, છતાં એવી સ્થિતિ પરત આપે જે લેખકના ઇરાદાની વિરુદ્ધ અર્થ ધરાવે. પહેલાં કરાર વાંચો અને તેની આસપાસ એડેપ્ટર લખો, પછી આખો એ ભૂલવર્ગ અદૃશ્ય થઈ જાય છે.
કરાર નાનો છે: સબમિટ કરેલું ખાતું ઓળખો, મંજૂર ચકાસણીકર્તાને ઇચ્છિત પ્રશ્ન પૂછો અને તે વિનંતી માટે ફક્ત તે ચકાસણીકર્તાનું દસ્તાવેજીકૃત હકારાત્મક પરિણામ સ્વીકારો. બાકી બધું ઇન્ફ્રાસ્ટ્રક્ચર છે.
હૂક પરત આપી શકે તેવી ત્રણ સ્થિતિઓ
auth-user-pass-verify માટે OpenVPN 2.6 મેન્યુઅલ એક્ઝિટ કોડ 0 ને સ્વીકાર, 1 ને નકાર અને 2 ને મુલતવી પ્રમાણીકરણ તરીકે વ્યાખ્યાયિત કરે છે. સર્વર સમજે છે તેવા ફક્ત આ ત્રણ જ જવાબો છે, અને દરેકનું જોડાણ પર અલગ પરિણામ છે. જે સ્ક્રિપ્ટ તેના છેલ્લા આદેશની સ્થિતિ સાથે બહાર નીકળે છે તેણે વાસ્તવમાં લોગ કૉલ કે સફાઈના પગલાને મત આપવા દીધો છે. દરેક શાખામાં સ્થિતિ સ્પષ્ટ રીતે લખો, એ શાખાઓમાં પણ જે ક્યારેય ચકાસણીકર્તા સુધી પહોંચી નહોતી.
HTTP સફળતા અને પ્રમાણીકરણ સફળતા અલગ સ્તરો છે, અને તેમને ભેગા કરવા એ આ હૂક ખોટો જવાનો સૌથી સામાન્ય રસ્તો છે. 202 પ્રતિસાદનો અર્થ છે કે વિનંતી પ્રક્રિયા માટે સ્વીકારાઈ છે, એ નહીં કે પાસવર્ડ ચકાસાયો છે. અપેક્ષિત સ્થિતિ, પ્રતિસાદનો આકાર અને અંતિમ ચુકાદો તમને આપેલા API કરારમાંથી નક્કી કરો, અને વિશ્વસનીય લાગે છે એટલા માટે કોઈ ફીલ્ડનું નામ શોધી ન કાઢો.
જો જવાબ ખરેખર પછી આવે, તો તે મુલતવી માર્ગ છે અને તેને એ રીતે જ બનાવવો પડશે. જે મુલતવી પ્રયાસ ક્યારેય પૂરો થતો નથી તે સમયમર્યાદા પૂરી થાય ત્યાં સુધી સંસાધનો રોકી રાખે છે.
ક્રેડેન્શિયલ ફાઇલ જેમ લખાઈ છે તેમ જ વાંચો
દસ્તાવેજીકૃત ફાઇલ દ્વારા પદ્ધતિમાં, સર્વર વપરાશકર્તાનામ અને પાસવર્ડને કામચલાઉ ફાઇલની પ્રથમ બે લાઇન તરીકે લખે છે, તે પાથ સ્ક્રિપ્ટને આપે છે અને સ્ક્રિપ્ટ પાછી ફરે ત્યારે ફાઇલ દૂર કરે છે. એ બે લાઇનને ડેટા તરીકે વાંચો: ફાઇલને ક્યારેય source કરશો નહીં, તેનું મૂલ્યાંકન ક્યારેય કરશો નહીં, અને તેનું સર્વસ્વ ક્યારેય એવી આદેશ લાઇનમાં પેસ્ટ કરશો નહીં જ્યાં પ્રોસેસ ટેબલ તેને જોઈ શકે. પાસવર્ડ બાઇટ દીઠ બાઇટ સાચવો, કારણ કે વપરાશકર્તાનામની જેમ તેને સામાન્ય બનાવવું ક્રેડેન્શિયલને ચૂપચાપ બદલે છે. એ કામચલાઉ ફાઇલ માટે વપરાતી ડિરેક્ટરી એ ડિપ્લોયમેન્ટ નિર્ણય છે, તેથી ખાતરી કરો કે તે અસ્તિત્વમાં છે અને હોસ્ટ પર બધા માટે વાંચી શકાય તેવી નથી.
ચકાસણીકર્તાનું પોતાનું ક્રેડેન્શિયલ વપરાશકર્તાના ક્રેડેન્શિયલથી અલગ રાખો: તે ગેટવે એકીકરણનું છે, પ્લેટફોર્મના સિક્રેટ સ્ટોરમાં રહે છે અને ફક્ત ચકાસવાની પરવાનગી જરૂરી છે, તેથી તે કોઈ ચોક્કસ વ્યક્તિ પ્રમાણીકૃત થઈ તેનો પુરાવો નથી. હૂકને બીજો પાસવર્ડ ચકાસણીકર્તા પણ બનવા દેશો નહીં. હાશ સરખામણી હાથે ફરી લખવી લૂપ ઑપ્ટિમાઇઝ કરવાથી સુરક્ષિત થતી નથી, અને જાળવાયેલો ચકાસણીકર્તા ખાતા સ્ટોરની મીઠાયુક્ત અને ખર્ચાળ યોજના પહેલેથી સમજે છે.
વર્ગીકૃત ન કરી શકાય તેવા જવાબનો અર્થ નક્કી કરો
સમયમર્યાદા, પરિવહન ભૂલો, વિકૃત પ્રતિસાદો અને અનુપલબ્ધ બેકએન્ડ એક ગુણધર્મ વહેંચે છે: તેમાંથી કોઈ હકારાત્મક ચકાસણી નથી. હૂકે તેમાંથી દરેક માટે બંધ થઈને નિષ્ફળ જવું જોઈએ અને એવું કારણ નોંધવું જોઈએ જેના પર ઓપરેટર પગલાં લઈ શકે. એ કારણ સુરક્ષિત લોગમાં હોવું જોઈએ, જોડાવા પ્રયત્ન કરતી વ્યક્તિને પરત આપેલા સંદેશમાં નહીં.
જે માર્ગો ચકાસણીકર્તા સુધી બિલકુલ પહોંચતા નથી તેમની સાથે પણ એટલી જ સાવધાની રાખો. ખૂટતું રૂપરેખાંકન મૂલ્ય, વાંચી ન શકાય તેવું સિક્રેટ કે ઇન્સ્ટોલ ન કરેલી નિર્ભરતા આકસ્મિક સ્વીકારને બદલે અલગ ઓપરેશનલ ચિહ્ન સાથે નકાર પેદા કરવો જોઈએ. એ શાખાઓને લેબમાં નિર્ભરતા દૂર કરીને ચકાસો, તેમના વિશે વિચારવાને બદલે. જ્યાં લોગ કરવામાં નિષ્ફળતા એક્ઝિટ સ્થિતિ બદલી શકે છે, ત્યાં લોગિંગ નિર્ણયનો ભાગ બની ગયું છે અને તેને નિરુપદ્રવી બનાવવું પડશે.
સર્વર રૂપરેખાંકન પણ અહીં મહત્વનું છે: વપરાશકર્તા-વ્યાખ્યાયિત સ્ક્રિપ્ટોને ફક્ત ત્યારે જ માન્યતા મળે છે જ્યારે ચાલુ રૂપરેખાંકન જરૂરી સુરક્ષા સ્તરે તેમને મંજૂરી આપે છે, અને એ સેટિંગ વધારવાની ડિફૉલ્ટ નહીં પણ જાણી જોઈને કરેલી પસંદગી છે.
ચુકાદો ચકાસો, છાપેલી લાઇન નહીં
એવી કસોટી બનાવો જે એક્ઝિટ સ્થિતિને સીધી તપાસે. નમૂનાની ક્રેડેન્શિયલ ફાઇલ લખો, જાણીતા-સારા અને જાણીતા-ખરાબ ખાતા સાથે તેની સામે હૂક ચલાવો, અને સ્ક્રિપ્ટ જે ટેક્સ્ટ છાપે તેને બદલે શેલ જે સ્થિતિ જણાવે તે વાંચો. એ એક જ તપાસ ક્લાયન્ટ જોડાય તે પહેલાં મોટાભાગની કરાર-ભૂલો પકડી લે છે.
પછી એ જ કેસોને વાસ્તવિક ક્લાયન્ટ દ્વારા બિન-ઉત્પાદન શ્રોતા સામે ચલાવો અને સર્વરે શું નોંધ્યું તેની ખાતરી કરો: સ્વીકૃત, નકારેલ અથવા મુલતવી. નિષ્ક્રિય ખાતું, ખોટો પાસવર્ડ, વિકૃત ચકાસણીકર્તા પ્રતિસાદ, સમયમર્યાદા અને અપ્રાપ્ય ચકાસણીકર્તા આવરી લો. જો કોઈ કેસ એવી સ્થિતિમાં આવે જેને તમે નામ આપી શકતા નથી, તો એડેપ્ટર પૂરું થયું નથી.
ચકાસણીકર્તાના પરિણામથી એક્ઝિટ સ્થિતિ સુધીનું મેપિંગ રિપોઝિટરીમાં સ્ક્રિપ્ટની બાજુમાં રાખો, જેથી આગલો એન્જિનિયર કોડની ઉલટી એન્જિનિયરિંગ કર્યા વિના કરાર વાંચી શકે.