Access Server ignorerar post_auth-skriptet du redigerade på disken

Ett redigerat mac.py som inte ändrar något är det vanliga första symptomet. Filen på disken är inte det Access Server kör; autentiseringstjänsten läser in skriptet från serverns konfigurationsdatabas, och just den sparade kopian avgör en inloggning. Tills det sparade värdet är ersatt bevisar varje test bara att det gamla skriptet fortfarande fungerar.

Tre villkor avgör arbetet: om värdet någonsin lades i konfigurationsdatabasen, om tjänsten fick order att läsa in det igen, och om koden du ändrade verkligen körs vid varje anslutning. Varje villkor har ett eget symptom, och att rätta det felaktiga slösar bort ett underhållsfönster.

Filen är en källa, inte den körande kopian

Access Server håller post-auth-skriptet under nyckeln auth.module.post_auth_script. Att redigera filen uppdaterar bara din arbetskopia. Daemonen läser det sparade värdet, så ändringen förblir osynlig tills du tar bort den gamla posten och sätter den nya filen på dess plats. Det sparade värdet är den enda kopia autentiseringstjänsten kontrollerar.

Läs det innan du ändrar det. Om det redan stämmer med filen du redigerade ligger problemet inte i lagringen och du kan gå vidare till frågan om omfattning. Om det visar en äldre version nådde ändringen aldrig tjänsten.

./sacli -k auth.module.post_auth_script ConfigGet

Ersätt den sparade kopian och tillämpa den sedan

Att radera före skrivning är inte utsmyckning. ConfigPut med --value_file ersätter värdet i ett steg, och ConfigDel först gör det omöjligt att lämna kvar en inaktuell eller skadad post. Spara en kopia av det fungerande skriptet utanför skriptmappen innan du börjar.

./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 tillämpar den ändrade konfigurationen på de interna tjänsterna, och det är detta som får det nya skriptet att gälla. Det är inte samma sak som att starta om hela maskinen eller daemonen, och det bör inte ersättas av det om inte din ändring kräver det.

Använd en absolut sökväg till värdefilen och bekräfta att root kan läsa den. En sökväg som löses från ditt skal men inte från tjänstekontot ger ett sparat värde som ser korrekt ut i ConfigGet och misslyckas vid första inloggningen. Kontrollera det sparade resultatet en gång till efter sacli start, inte före.

Modulomfattning eller per anslutning: var frågan hör hemma

Python kör satser på modulnivå en gång, när skriptet läses in. En databasfråga som skrivs högst upp i filen läser därför tabellen vid inläsningen och behåller svaret för varje senare anslutning. Det är den andra orsaken till att en ändring verkar göra ingenting: koden körs, men inte när du förväntar dig det.

Lägg frågan inuti post_auth-hanteraren så att den körs vid varje autentisering. Behåll den dokumenterade signaturen, justera autentiseringsresultatet som hanteraren tar emot, och returnera samma objekt i stället för ett bart tal.

Håll också anslutningshanteringen inuti hanteraren. En anslutning som öppnas vid import kan stängas av servern innan den första användaren loggar in, och felet som uppstår ser ut som avvisade inloggningsuppgifter snarare än ett trasigt skript.

Två avvisningsvägar, en ägare

Om beslutet är en lokal fråga äger Python-hanteraren resultatet. Om det är en extern HTTP-kontroll låter du kommandots utgångsstatus bära svaret: ett omslag som avslutas med ett värde skilt från noll avvisar inloggningen, och det sista kommandots status blir skriptets status utan en uttrycklig exit.

Håll hemligheten utanför processlistan. En fil som root kan läsa eller ett miljövärde som tjänsten skickar vidare är säkrare än ett argument som vilken lokal användare som helst kan läsa från ps. Fäst slutpunkten i en variabel före anropet, så att ett skrivfel fallerar vid konfigurationen och inte under någons inloggning. Rotera den hemligheten som alla andra inloggningsuppgifter.

Välj en ägare per kontroll. Ett skript som både frågar databasen och anropar en HTTP-tjänst behöver en uttalad prioritetsregel för fallet då de två är oense, annars stämmer inte avvisningsorsaken i loggen med det användaren fick höra.

Tillämpa det utan att låsa ute administratören

Two skyddsåtgärder gör ändringen återställbar: ett extra administratörskonto som inte beror på skriptet, och en känd god kopia som förvaras utanför skriptmappen. Tillämpa ändringen i ett underhållsfönster och följ sedan en testinloggning och en avsiktlig avvisning innan du kopplar från. Om loggen visar ett syntaxfel i stället för ett autentiseringsbeslut är det sparade skriptet trasigt och varje inloggning kommer att misslyckas.

Två villkor säger vänta: du kan inte läsa värdefilen som root, eller du har ingen andra väg in i administrationsgränssnittet. Båda gör en liten ändring till en utelåsning, och ingen av dem är värd att testa på en produktionsserver i slutet av dagen. Dokumentationen för Access Server täcker post-auth-gränssnittet och dess stödda fält.