Access Server ignorerer post_auth-skriptet du redigerte på disken

Eit redigert mac.py som ikkje endrar noko, er det vanlege fyrste symptomet. Fila på disken er ikkje det Access Server køyrer; autentiseringstenesta lastar skriptet frå konfigurasjonsdatabasen til tenaren, og nettopp den lagra kopien avgjer ei innlogging. Så lenge den lagra verdien ikkje er bytt ut, provar kvar test berre at det gamle skriptet enno verkar.

Tre vilkår avgjer arbeidet: om verdien nokon gong vart lagd i konfigurasjonsdatabasen, om tenesta fekk beskjed om å lasta han på nytt, og om koden du endra faktisk køyrer ved kvar tilkopling. Kvart vilkår har eit anna symptom, og å retta det gale øydar eit vedlikehaldsvindauge.

Fila er ei kjelde, ikkje den køyrande kopien

Access Server held post-auth-skriptet under nøkkelen auth.module.post_auth_script. Å redigere fila oppdaterer berre arbeidskopien din. Daemonen les den lagra verdien, så endringa blir usynleg til du slettar den gamle oppføringa og set den nye fila på plassen hennar. Den lagra verdien er den einaste kopien autentiseringstenesta ser på.

Les han før du endrar han. Om han alt svarar til fila du redigerte, er ikkje problemet lagringa, og du bør gå vidare til spørsmålet om omfang. Om han viser ein eldre versjon, nådde endringa aldri tenesta.

./sacli -k auth.module.post_auth_script ConfigGet

Byt ut den lagra kopien, og bruk han deretter

Å sletta før ein skriv er ikkje pynt. ConfigPut med --value_file byter ut verdien i eitt steg, og ConfigDel fyrst gjer det umogleg å etterlata ei utdatert eller skadd oppføring. Tak vare på ein kopi av det fungerande skriptet utanfor skriptmappa før du byrjar.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start brukar den endra konfigurasjonen på dei interne tenestene, og det er dette som gjer at det nye skriptet tek til å gjelda. Det er ikkje det same som å starta heile maskina eller daemonen på nytt, og det bør ikkje bytast ut med det med mindre endringa di krev det.

Bruk ein absolutt veg til verdifila og stadfest at root kan lesa henne. Ein veg som blir løyst frå skalet ditt men ikkje frå tenestekontoen, gir ein lagra verdi som ser rett ut i ConfigGet og sviktar ved fyrste innlogging. Kontroller den lagra verdien ein gong til etter sacli start, ikkje før.

Modulumfang eller per tilkopling: kvar oppslaget høyrer heime

Python køyrer setningar på modulnivå éin gong, når skriptet blir lasta. Ei databasespørjing som er skriven øvst i fila, les derfor tabellen ved lasting og held på svaret for kvar seinare tilkopling. Det er den andre grunnen til at ei endring ser ut til å gjera ingenting: koden køyrer, men ikkje når du ventar det.

Legg spørjinga inni post_auth-handsamaren slik at ho blir køyrd ved kvar autentisering. Hald på den dokumenterte signaturen, juster autentiseringsresultatet handsamaren får, og returner det same objektet i staden for eit bert tal.

Hald òg tilkoplingshandteringa inni handsamaren. Ei tilkopling som blir opna ved import, kan bli stengd av tenaren før den fyrste brukaren loggar inn, og feilen som kjem, ser ut som avviste påloggingsdata snarare enn eit øydelagt skript.

To avvisingvegar, éin eigar

Er avgjerda eit lokalt oppslag, eig Python-handsamaren resultatet. Er det ein ekstern HTTP-kontroll, lat utgangsstatusen til kommandoen bera svaret: ei innpakning som går ut med ein verdi ulik null, avviser innlogginga, og statusen til den siste kommandoen blir statusen til skriptet utan ein eksplisitt exit.

Hald løyndomen utanfor prosesslista. Ei fil som root kan lesa, eller ein miljøverdi tenesta sender vidare, er tryggare enn eit argument som kvar lokal brukar kan lesa frå ps. Fest endepunktet i ein variabel før kallet, slik at ein skrivefeil sviktar ved konfigurering og ikkje under innlogginga til nokon. Roter den løyndomen på same måte som alle andre påloggingsdata.

Vel éin eigar per kontroll. Eit skript som både spør databasen og kallar ein HTTP-teneste, treng ein erklært prioritetsregel for tilfellet der dei to er usamde, elles vil avvisingsgrunnen i loggen ikkje stemma med det brukaren fekk vita.

Bruk det utan å låsa administratoren ute

To tryggingar gjer endringa reversibel: ein ekstra administratorkonto som ikkje er avhengig av skriptet, og ein kjend god kopi som blir oppbevart utanfor skriptmappa. Bruk endringa i eit vedlikehaldsvindauge, og fylg deretter med på éi prøveinnlogging og éi medviten avvising før du koplar frå. Om loggen viser ein syntaksfeil i staden for ei autentiseringsavgjerd, er det lagra skriptet øydelagt, og kvar innlogging vil svikta.

To vilkår seier vent: du kan ikkje lesa verdifila som root, eller du har ingen annan veg inn i administrasjonsgrensesnittet. Begge gjer ei lita endring til ei utelåsing, og ingen av dei er verdt å prøva på ein produksjonstenar seint på dagen. Dokumentasjonen for Access Server dekkjer post-auth-grensesnittet og felta det støttar.