OpenVPN-skrip auth-user-pass-verify: kry die uitkode reg

OpenVPN handel op presies een uitset van ’n aanmeldskrip: die uitkodestatus. Alles anders wat die skrip doen, is versiering. ’n Haak kan die regte verifieerder bereik, die antwoord ontleed en ’n vriendelike reël druk terwyl dit ’n status teruggee wat die teenoorgestelde beteken van wat die skrywer bedoel het. Lees eers die kontrak en skryf die adapter daar rondom, dan verdwyn daardie hele klas foute.

Die kontrak is klein: identifiseer die rekening wat ingedien is, vra die goedgekeurde verifieerder die bedoelde vraag, en aanvaar net daardie verifieerder se gedokumenteerde positiewe resultaat vir daardie versoek. Al die res is loodgieterswerk.

Die drie statusse wat die haak kan teruggee

Vir auth-user-pass-verify, die OpenVPN 2.6-handleiding definieer uitkode 0 as aanvaarding, 1 as verwerping en 2 as uitgestelde verifikasie. Dit is die enigste drie antwoorde wat die bediener verstaan, en elkeen het ’n ander gevolg vir die verbinding. ’n Skrip wat met die status van sy laaste opdrag uitgaan, het in effek ’n logoproep of ’n opruimstap laat stem. Skryf die status eksplisiet in elke tak, ook in die takke wat nooit die verifieerder bereik het nie.

HTTP-sukses en verifikasiesukses is aparte lae, en om hulle te verwar is die mees algemene manier waarop hierdie haak verkeerd gaan. ’n 202-antwoord beteken die versoek is aanvaar vir verwerking, nie dat ’n wagwoord geverifieer is nie. Definieer die verwagte status, die vorm van die antwoord en die finale uitspraak uit die API-kontrak wat jy gekry het, en moenie ’n veldnaam uitdink omdat dit geloofwaardig lyk nie.

As die antwoord werklik later kom, is dit die uitgestelde pad en dit moet as sodanig gebou word. ’n Uitgestelde poging wat nooit voltooi word nie, hou hulpbronne vas totdat die tydlimiet verstryk.

Lees die geloofsbrieflêer presies soos dit geskryf is

Met die gedokumenteerde via-lêer-metode skryf die bediener die gebruikersnaam en wagwoord as die eerste twee reëls van ’n tydelike lêer, gee daardie pad aan die skrip, en verwyder die lêer wanneer die skrip terugkeer. Lees daardie twee reëls as data: moenie die lêer source nie, moenie dit evalueer nie, en moenie die inhoud daarvan in ’n opdragreël plak waar die prosestabel dit kan sien nie. Bewaar die wagwoord byte vir byte, want om dit te normaliseer soos jy ’n gebruikersnaam sou normaliseer, verander die geloofsbrief stilweg. Die gids wat vir daardie tydelike lêer gebruik word, is ’n ontplooiingsbeslissing, so bevestig dat dit bestaan en nie vir almal op die gasheer leesbaar is nie.

Hou die verifieerder se eie geloofsbrief apart van die gebruiker s’n: dit behoort aan die gateway-integrasie, woon in die platform se geheimebergplek, en het net die toestemming nodig om te verifieer, so dit is nie bewyse dat enige spesifieke persoon geauthentiseer het nie. Moenie toelaat dat die haak ’n tweede wagwoordverifieerder word nie. Om ’n hashvergelyking met die hand te herimplementeer word nie veilig gemaak deur die lus te optimaliseer nie, en ’n onderhoude verifieerder verstaan reeds die rekeningstoor se gesoute, koste-gebaseerde skema.

Bepaal wat ’n onklassifiseerbare antwoord beteken

Tydlimiete, vervoerfoute, wanvormige antwoorde en ’n onbeskikbare backend deel een eienskap: nie een daarvan is ’n positiewe verifikasie nie. Die haak moet vir elkeen daarvan gesluit faal en ’n rede aanteken waarop ’n operateur kan reageer. Daardie rede hoort in ’n beskermde log, nie in ’n boodskap aan die persoon wat probeer koppel nie.

Wees ewe versigtig met die paaie wat die verifieerder glad nie bereik nie. ’n Ontbrekende konfigurasiewaarde, ’n onleesbare geheim of ’n afhanklikheid wat nie geïnstalleer is nie, moet ’n verwerping met ’n duidelike operasionele merker lewer eerder as ’n toevallige aanvaarding. Toets daardie takke deur die afhanklikheid in ’n laboratorium te verwyder eerder as om daaroor te redeneer. Waar ’n mislukking om te log die uitkodestatus kan verander, het die log deel van die beslissing geword en moet dit onskadelik gemaak word.

Bedienerkonfigurasie maak hier ook saak: gebruikergedefinieerde skripte word net geëer wanneer die lopende konfigurasie hulle op die vereiste sekuriteitsvlak toelaat, en daardie instelling is ’n doelbewuste keuse eerder as ’n verstekwaarde om te verhoog.

Verifieer die uitspraak, nie die gedrukte reël nie

Bou ’n toets wat die uitkodestatus direk inspekteer. Skryf ’n voorbeeld-geloofsbrieflêer, hardloop die haak daarteen met ’n bekende-goeie en ’n bekende-slegte rekening, en lees die status wat die skulp rapporteer eerder as die teks wat die skrip druk. Daardie enkele kontrole vang die meeste kontrakfoute voordat ’n kliënt ooit koppel.

Hardloop dan dieselfde gevalle deur ’n werklike kliënt teen ’n nie-produksie-luisteraar en bevestig wat die bediener aangeteken het: aanvaar, verwerp of uitgestel. Dek ’n gedeaktiveerde rekening, ’n verkeerde wagwoord, ’n wanvormige verifieerderantwoord, ’n tydlimiet en ’n onbereikbare verifieerder. As enige geval in ’n toestand beland wat jy nie kan benoem nie, is die adapter nie klaar nie.

Hou die kartering van verifieerderuitslag na uitkodestatus langs die skrip in die bewaarplek, sodat die volgende ingenieur die kontrak kan lees sonder om die kode om te keer.