OpenVPN-skriptet auth-user-pass-verify: rett utgangskode

OpenVPN handlar på nøyaktig éin utgang frå eit innloggingsskript: utgangsstatusen. Alt anna skriptet gjer, er dekorasjon. Ein krok kan nå rett verifikatør, tolke svaret og skrive ut ei venleg linje, men returnere ein status som tyder det motsette av det forfattaren meinte. Les kontrakten først og skriv adapteren rundt han, så forsvinn heile den feilklassen.

Kontrakten er liten: identifiser kontoen som vart send, spør den godkjende verifikatøren det tiltenkte spørsmålet, og godta berre det dokumenterte positive resultatet frå den verifikatøren for den førespurnaden. Alt anna er infrastruktur.

Dei tre statusane kroken kan returnere

For auth-user-pass-verify, OpenVPN 2.6-handboka definerer utgangskode 0 som aksept, 1 som avvising og 2 som utsett autentisering. Det er dei einaste tre svara serveren forstår, og kvart av dei har ei anna følgje for tilkoplinga. Eit skript som avsluttar med statusen frå sin siste kommando, har i praksis late eit loggkall eller eit oppryddingssteg stemme. Skriv statusen eksplisitt i kvar grein, òg i greinene som aldri nådde verifikatøren.

HTTP-suksess og autentiseringssuksess er skilde lag, og å blande dei er den vanlegaste måten denne kroken går gale. Eit 202-svar tyder at førespurnaden er godteken for handsaming, ikkje at eit passord er verifisert. Definer forventa status, forma på svaret og den endelege dommen ut frå API-kontrakten du fekk, og ikkje finn opp eit feltnamn fordi det verkar truleg.

Viss svaret verkeleg kjem seinare, er det den utsette vegen, og han må byggjast som slik. Eit utsett forsøk som aldri vert fullført, held ressursar til tidsavbrotet renn ut.

Les legitimasjonsfila nøyaktig slik ho er skriven

Med den dokumenterte via-fil-metoden skriv serveren brukarnamn og passord som dei to første linjene i ei mellombels fil, sender stien til skriptet og fjernar fila når skriptet kjem attende. Les dei to linjene som data: køyr aldri fila gjennom source, evaluer ho aldri, og lim aldri innhaldet inn i ei kommandolinje der prosesstabellen kan sjå det. Ta vare på passordet byte for byte, fordi normalisering, slik du ville normalisert eit brukarnamn, stille endrar legitimasjonen. Katalogen for den mellombelse fila er ei driftsavgjerd, så stadfest at han finst og ikkje er lesbar for alle på verten.

Hald verifikatøren sin eigen legitimasjon skild frå brukaren sin: han høyrer til gateway-integrasjonen, bur i hemmelegheitslageret til plattforma og treng berre løyvet til å verifisere, så han er ikkje prov på at ein bestemt person er autentisert. Ikkje lat kroken bli ein andre passordverifikatør heller. Handskriven hash-samanlikning vert ikkje trygg av å optimalisere løkka, og ein vedlikehalden verifikatør forstår allereie den salta og kostbare ordninga til kontolageret.

Avgjer kva eit uklassifiserbart svar tyder

Tidsavbrot, transportfeil, øydelagde svar og ein utilgjengeleg backend deler éin eigenskap: ingen av dei er ei positiv verifisering. Kroken bør svikte lukka for kvar av dei og registrere ein grunn som ein operatør kan handle på. Den grunnen høyrer i ein verna logg, ikkje i ei melding som vert returnert til personen som prøver å kople til.

Ver like nøye med vegane som ikkje når verifikatøren i det heile. Ein manglande konfigurasjonsverdi, ein uleseleg hemmelegheit eller ein avhengnad som ikkje er installert bør gje ei avvising med ein tydeleg operativ markør i staden for ein tilfeldig aksept. Test dei greinene ved å fjerne avhengnaden i eit laboratorium i staden for å resonnere om dei. Der ein feil i logginga kan endre utgangsstatusen, er logginga vorte ein del av avgjerda og må gjerast ufarleg.

Serverkonfigurasjon har noko å seie her òg: brukardefinerte skript vert respekterte berre når den køyrande konfigurasjonen tillèt dei på det påkravde tryggingsnivået, og den innstillinga er eit medvite val og ikkje ein standardverdi som skal hevast.

Verifiser dommen, ikkje den utskrivne linja

Bygg ein test som granskar utgangsstatusen direkte. Skriv ei prøvelegitimasjonsfil, køyr kroken mot ho med ein kjend god og ein kjend dårleg konto, og les statusen som skalet rapporterer i staden for teksten skriptet skriv ut. Den eine kontrollen fangar dei fleste kontraktfeila før ein klient i det heile koplar til.

Køyr deretter dei same tilfella gjennom ein ekte klient mot ein ikkje-produksjonslyttar og stadfest kva serveren registrerte: godteke, avvist eller utsett. Dekk ein deaktivert konto, feil passord, eit øydelagt verifikatørsvar, eit tidsavbrot og ein utilgjengeleg verifikatør. Viss noko tilfelle hamnar i ein tilstand du ikkje kan namngje, er adapteren ikkje ferdig.

Hald koplinga frå verifikatørresultat til utgangsstatus ved sida av skriptet i repositoriet, slik at neste ingeniør kan lese kontrakten utan å reversere koden.