OpenVPN-skripto auth-user-pass-verify: ĝusta elirkodo

OpenVPN agas laŭ ekzakte unu eligo de ensaluta skripto: la elirstato. Ĉio alia, kion la skripto faras, estas ornamo. Hoko povas atingi la ĝustan kontrolilon, analizi la respondon kaj presi afablan linion, dum ĝi redonas staton, kiu signifas la malon de tio, kion ĝia aŭtoro intencis. Legu unue la kontrakton kaj skribu la adaptilon ĉirkaŭ ĝi, kaj tiu tuta klaso de cimoj malaperas.

La kontrakto estas malgranda: identigu la konton, kiu estis sendita, demandu al la aprobita kontrolilo la intencitan demandon, kaj akceptu nur la dokumentitan pozitivan rezulton de tiu kontrolilo por tiu peto. Ĉio alia estas substrukturo.

La tri statoj, kiujn la hoko povas redoni

Por auth-user-pass-verify, la manlibro de OpenVPN 2.6 difinas elirkodon 0 kiel akcepton, 1 kiel malakcepton kaj 2 kiel prokrastitan aŭtentikigon. Tiuj estas la solaj tri respondoj, kiujn la servilo komprenas, kaj ĉiu havas alian sekvon por la konekto. Skripto, kiu eliras kun la stato de sia lasta komando, fakte lasis logvokon aŭ purigpaŝon voĉdoni. Skribu la staton eksplicite en ĉiu branĉo, inkluzive de la branĉoj, kiuj neniam atingis la kontrolilon.

HTTP-sukceso kaj aŭtentikiga sukceso estas apartaj tavoloj, kaj ilin konfuzi estas la plej ofta maniero, kiel ĉi tiu hoko eraras. Respondo 202 signifas, ke la peto estis akceptita por prilaboro, ne ke pasvorto estis kontrolita. Difinu la atendatan staton, la formon de la respondo kaj la finan verdikton el la API-kontrakto, kiun vi ricevis, kaj ne elpensu kamponomon ĉar ĝi ŝajnas kredinda.

Se la respondo vere alvenas poste, tio estas la prokrastita vojo kaj ĝi devas esti konstruita tiel. Prokrastita provo, kiu neniam finiĝas, tenas rimedojn ĝis la tempo limo eksvalidiĝas.

Legu la akreditan dosieron ĝuste tiel, kiel ĝi estas skribita

Per la dokumentita metodo per dosiero, la servilo skribas la uzantnomon kaj pasvorton kiel la unuajn du liniojn de provizora dosiero, transdonas tiun vojon al la skripto kaj forigas la dosieron, kiam la skripto revenas. Legu tiujn du liniojn kiel datumojn: neniam rulu la dosieron per source, neniam taksu ĝin, kaj neniam algluu ĝian enhavon en komandlinion, kie la proceza tabelo povas vidi ĝin. Konservu la pasvorton bajton post bajto, ĉar normaligado, kiun vi eble aplikus al uzantnomo, silente ŝanĝas la akrediton. La dosierujo por tiu provizora dosiero estas deplojdecido, do konfirmu, ke ĝi ekzistas kaj ne estas legebla de ĉiuj en la gastiganto.

Tenu la propran akrediton de la kontrolilo aparte de tiu de la uzanto: ĝi apartenas al la enirporda integriĝo, loĝas en la sekreta deponejo de la platformo kaj bezonas nur la permeson kontroli, do ĝi ne estas pruvo, ke iu konkreta persono aŭtentikiĝis. Ne lasu la hokon fariĝi dua pasvorta kontrolilo. Mana reimplementado de haketkomparo ne fariĝas sekura per optimumigo de la buklo, kaj prizorgata kontrolilo jam komprenas la salitan kaj multekostan skemon de la konta deponejo.

Decidu, kion signifas neklasifikebla respondo

Temolimoj, transportaj eraroj, misformitaj respondoj kaj neatingebla malantaŭa sistemo kunhavas unu econ: neniu el ili estas pozitiva kontrolo. La hoko devus malsukcesi fermite por ĉiu el ili kaj registri kialon, pri kiu operacianto povas agi. Tiu kialo apartenas al protektita logilo, ne al mesaĝo redonata al la persono, kiu provas konektiĝi.

Estu same atenta pri la vojoj, kiuj tute ne atingas la kontrolilon. Mankanta agorda valoro, nelegebla sekreto aŭ neinstalita dependaĵo devus produkti malakcepton kun distinga operacia markilo anstataŭ hazarda akcepto. Testu tiujn branĉojn per forigo de la dependaĵo en laboratorio anstataŭ rezonadi pri ili. Kie malsukceso registri povas ŝanĝi la elirstaton, la registrado fariĝis parto de la decido kaj devas esti farita sendanĝera.

Servila agordo gravas ankaŭ ĉi tie: uzantodifinitaj skriptoj estas respektataj nur kiam la kuranta agordo permesas ilin je la postulata sekurecnivelo, kaj tiu agordo estas intenca elekto, ne defaŭlto por plialtigi.

Kontrolu la verdikton, ne la presitan linion

Konstruu teston, kiu rekte inspektas la elirstaton. Skribu specimenan akreditan dosieron, rulu la hokon kontraŭ ĝi kun konate bona kaj konate malbona konto, kaj legu la staton, kiun raportas la ŝelo, anstataŭ la tekston, kiun presas la skripto. Tiu unu kontrolo kaptas la plej multajn kontraktajn cimojn antaŭ ol kliento eĉ konektiĝas.

Poste rulu la samajn kazojn tra reala kliento kontraŭ neprodukta aŭskultanto kaj konfirmu, kion la servilo registris: akceptita, malakceptita aŭ prokrastita. Kovru malŝaltitan konton, malĝustan pasvorton, misformitan kontrolilan respondon, temolimon kaj neatingeblan kontrolilon. Se iu kazo finiĝas en stato, kiun vi ne povas nomi, la adaptilo ne estas finita.

Tenu la mapadon de kontrolila rezulto al elirstato apud la skripto en la deponejo, por ke la sekva inĝeniero povu legi la kontrakton sen rea inĝenierado de la kodo.