Access Server negeert het post_auth-script dat je op de schijf hebt bewerkt

Een bewerkt mac.py dat niets verandert, is het gebruikelijke eerste symptoom. Het bestand op de schijf is niet wat Access Server uitvoert; de authenticatiedienst laadt het script uit de configuratiedatabase van de server, en juist die opgeslagen kopie bepaalt een aanmelding. Totdat de opgeslagen waarde is vervangen, bewijst elke test alleen dat het oude script nog werkt.

Drie voorwaarden bepalen het werk: of de waarde ooit in de configuratiedatabase is gezet, of de dienst is opgedragen die opnieuw te laden, en of de code die je hebt gewijzigd werkelijk bij elke verbinding draait. Elk heeft een ander symptoom, en het verkeerde oplossen verspilt een onderhoudsvenster.

Het bestand is een bron, niet de draaiende kopie

Access Server houdt het post-auth-script onder de sleutel auth.module.post_auth_script. Het bestand bewerken werkt alleen je werkkopie bij. De daemon leest de opgeslagen waarde, dus de wijziging blijft onzichtbaar tot je de oude regel verwijdert en het nieuwe bestand op zijn plaats zet. Die opgeslagen waarde is de enige kopie die de authenticatiedienst raadpleegt.

Lees die voordat je hem wijzigt. Komt hij al overeen met het bestand dat je hebt bewerkt, dan zit het probleem niet in de opslag en ga je door naar de vraag over de reikwijdte. Toont hij een oudere versie, dan heeft de wijziging de dienst nooit bereikt.

./sacli -k auth.module.post_auth_script ConfigGet

Vervang de opgeslagen kopie en pas hem daarna toe

Verwijderen voordat je schrijft is geen versiering. ConfigPut met --value_file vervangt de waarde in een enkele stap, en ConfigDel eerst maakt het onmogelijk een verouderde of beschadigde regel achter te laten. Bewaar een kopie van het werkende script buiten de scriptmap voordat je begint.

./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 past de gewijzigde configuratie toe op de interne diensten, en dat is wat het nieuwe script in werking stelt. Het is niet hetzelfde als de hele machine of de daemon opnieuw starten, en het mag daardoor niet worden vervangen tenzij je wijziging dat vereist.

Gebruik een absoluut pad voor het waardebestand en bevestig dat root het kan lezen. Een pad dat vanuit je shell wordt opgelost maar niet vanuit het dienstaccount, levert een opgeslagen waarde op die er in ConfigGet goed uitziet en bij de eerste aanmelding faalt. Controleer het opgeslagen resultaat nog één keer na sacli start, niet daarvoor.

Modulumvang of per verbinding: waar de query thuishoort

Python voert instructies op modulniveau één keer uit, bij het laden van het script. Een databasequery bovenaan het bestand leest de tabel dus bij het laden en houdt dat antwoord voor elke volgende verbinding. Dat is de tweede reden waarom een wijziging niets lijkt te doen: de code draait, maar niet wanneer je het verwacht.

Zet de query in de post_auth-handler zodat die bij elke authenticatie wordt uitgevoerd. Behoud de gedocumenteerde signatuur, pas het authenticatieresultaat aan dat de handler ontvangt, en geef hetzelfde object terug in plaats van een kaal getal.

Houd ook de verbindingsafhandeling in de handler. Een verbinding die bij het importeren wordt geopend, kan door de server worden gesloten voordat de eerste gebruiker inlogt, en de fout die dan ontstaat lijkt op geweigerde inloggegevens in plaats van een kapot script.

Twee afwijswegen, één eigenaar

Is de beslissing een lokale query, dan is de Python-handler eigenaar van het resultaat. Is het een externe HTTP-controle, laat dan de exitstatus van de opdracht het antwoord dragen: een wrapper die met een niet-nul code eindigt, weigert de aanmelding, en de status van de laatste opdracht wordt de status van het script zonder expliciete exit.

Houd het geheim buiten de proceslijst. Een bestand dat root kan lezen of een omgevingswaarde die de dienst doorgeeft, is veiliger dan een argument dat elke lokale gebruiker uit ps kan lezen. Zet het eindpunt in een variabele voordat je het aanroept, zodat een typefout bij de configuratie faalt en niet tijdens iemands aanmelding. Roteer dat geheim zoals je met elke andere inloggegevens doet.

Kies één eigenaar per controle. Een script dat zowel de database bevraagt als een HTTP-dienst aanroept, heeft een uitgesproken voorrangsregel nodig voor het geval de twee het oneens zijn, anders komt de afwijsreden in het logboek niet overeen met wat de gebruiker is verteld.

Pas het toe zonder de beheerder buiten te sluiten

Twee waarborgen maken de wijziging omkeerbaar: een tweede beheerdersaccount dat niet van het script afhankelijk is, en een bekend goede kopie buiten de scriptmap. Pas de wijziging toe in een onderhoudsvenster en kijk daarna naar één testaanmelding en één opzettelijke afwijzing voordat je de verbinding verbreekt. Als het logboek een syntaxisfout toont in plaats van een authenticatiebeslissing, is het opgeslagen script kapot en zal elke aanmelding mislukken.

Twee voorwaarden zeggen wacht: je kunt het waardebestand niet als root lezen, of je hebt geen tweede weg naar de beheerinterface. Beide maken van een kleine wijziging een buitensluiting, en geen van beide is het waard om aan het eind van de dag op een productieserver te testen. De documentatie van Access Server behandelt de post-auth-interface en de ondersteunde velden.