OpenVPN-scriptet auth-user-pass-verify: få exitkoden rigtig

OpenVPN handler på præcis ét output fra et login-script: exitstatusen. Alt andet, scriptet gør, er pynt. Et hook kan nå den rigtige verifikator, parse svaret og printe en venlig linje, mens det returnerer en status, der betyder det modsatte af, hvad forfatteren tilsigtede. Læs kontrakten først, og skriv adapteren omkring den, så forsvinder hele den klasse af fejl.

Kontrakten er lille: identificér den konto, der blev sendt, stil den godkendte verifikator det tilsigtede spørgsmål, og accepter kun den dokumenterede positive resultat fra den verifikator for den anmodning. Alt andet er infrastruktur.

De tre statusser, hooket kan returnere

For auth-user-pass-verify, OpenVPN 2.6-manualen definerer exitkode 0 som accept, 1 som afvisning og 2 som udskudt autentificering. Det er de eneste tre svar, serveren forstår, og hvert af dem har en forskellig konsekvens for forbindelsen. Et script, der afslutter med status fra sin sidste kommando, har reelt ladet et logkald eller et oprydningstrin stemme. Skriv status eksplicit i hver gren, også i de grene, der aldrig nåede verifikatoren.

HTTP-succes og autentificeringssucces er adskilte lag, og at blande dem er den mest almindelige måde, dette hook går galt. Et 202-svar betyder, at anmodningen er accepteret til behandling, ikke at en adgangskode er verificeret. Definer den forventede status, svarets form og den endelige dom ud fra den API-kontrakt, du fik, og opfind ikke et feltnavn, fordi det ser plausibelt ud.

Hvis svaret virkelig kommer senere, er det den udskudte vej, og den skal bygges som sådan. Et udskudt forsøg, der aldrig fuldføres, holder ressourcer, indtil timeouten udløber.

Læs legitimationsfilen præcis som den er skrevet

Med den dokumenterede via-fil-metode skriver serveren brugernavn og adgangskode som de to første linjer i en midlertidig fil, sender stien til scriptet og fjerner filen, når scriptet vender tilbage. Læs de to linjer som data: kør aldrig filen gennem source, evaluér den aldrig, og indsæt aldrig dens indhold i en kommandolinje, hvor procestabellen kan se det. Bevar adgangskoden byte for byte, fordi normalisering, som du måske ville bruge på et brugernavn, stille ændrer legitimationsoplysningerne. Mappen til den midlertidige fil er en driftsbeslutning, så bekræft, at den findes, og at den ikke kan læses af alle på værten.

Hold verifikatorens egne legitimationsoplysninger adskilt fra brugerens: de hører til gateway-integrationen, lever i platformens hemmelighedsbutik og har kun brug for tilladelsen til at verificere, så de er ikke bevis på, at en bestemt person er autentificeret. Lad heller ikke hooket blive en anden adgangskodeverifikator. Håndskrevet hash-sammenligning bliver ikke sikker af at optimere løkken, og en vedligeholdt verifikator forstår allerede kontoopbevaringens salte og bekostelige skema.

Beslut, hvad et uklassificerbart svar betyder

Timeouts, transportfejl, forvanskede svar og en utilgængelig backend deler én egenskab: ingen af dem er en positiv verifikation. Hooket bør svigte lukket for hver af dem og registrere en grund, som en operatør kan handle på. Den grund hører i en beskyttet log, ikke i en besked, der returneres til den person, der forsøger at forbinde.

Vær lige så omhyggelig med de veje, der slet ikke når verifikatoren. En manglende konfigurationsværdi, en ulæselig hemmelighed eller en afhængighed, der ikke er installeret, bør give en afvisning med en tydelig operationel markør i stedet for en utilsigtet accept. Test de grene ved at fjerne afhængigheden i et laboratorium i stedet for at ræsonnere om dem. Hvor en fejl i logningen kan ændre exitstatusen, er logningen blevet en del af beslutningen og skal gøres uskadelig.

Serverkonfiguration betyder noget her også: brugerskrevne scripts respekteres kun, når den kørende konfiguration tillader dem på det krævede sikkerhedsniveau, og den indstilling er et bevidst valg frem for en standard, der skal hæves.

Verificér dommen, ikke den udskrevne linje

Byg en test, der inspicerer exitstatusen direkte. Skriv en prøvelegitimationsfil, kør hooket mod den med en kendt god og en kendt dårlig konto, og læs den status, shellen rapporterer, i stedet for den tekst, scriptet udskriver. Den ene kontrol fanger de fleste kontraktfejl, før en klient overhovedet forbinder.

Kør derefter de samme sager gennem en rigtig klient mod en ikke-produktionslytter, og bekræft, hvad serveren registrerede: accepteret, afvist eller udskudt. Dæk en deaktiveret konto, en forkert adgangskode, et forvansket verifikatorsvar, en timeout og en utilgængelig verifikator. Hvis en sag ender i en tilstand, du ikke kan navngive, er adapteren ikke færdig.

Hold koblingen fra verifikatorresultat til exitstatus ved siden af scriptet i repositoriet, så den næste ingeniør kan læse kontrakten uden at reverse-engineere koden.