Access Server ignoruje skript post_auth, který jste upravili na disku
Úprava souboru post_auth na disku nic nedělá: Access Server spouští kopii ve své konfigurační databázi. Sledujte cestu rozhodnutí a příkazy sacli.
Upravený mac.py, který nic nemění, je obvyklý první příznak. Soubor na disku není to, co Access Server spouští; služba ověřování načítá skript z konfigurační databáze serveru a právě tato uložená kopie rozhoduje o přihlášení. Dokud se uložená hodnota nenahradí, každý test jen dokazuje, že starý skript stále funguje.
Práci určují tři podmínky: zda byla hodnota někdy vložena do konfigurační databáze, zda služba dostala pokyn ji znovu načíst a zda se změněný kód skutečně spouští při každém připojení. Každá má jiný příznak a oprava té špatné promarní servisní okno.
Soubor je zdroj, ne běžící kopie
Access Server drží skript post-auth pod klíčem auth.module.post_auth_script. Úprava souboru aktualizuje jen vaši pracovní kopii. Démon čte uloženou hodnotu, takže změna zůstává neviditelná, dokud nesmažete starý záznam a neumístíte nový soubor na jeho místo. Tato uložená hodnota je jediná kopie, kterou služba ověřování prohlíží.
Přečtěte ji, než ji změníte. Pokud už odpovídá souboru, který jste upravili, problém není v úložišti a přejděte k otázce rozsahu. Pokud ukazuje starší verzi, změna se ke službě nedostala.
./sacli -k auth.module.post_auth_script ConfigGetNahraďte uloženou kopii a potom ji použijte
Mazání před zápisem není ozdoba. ConfigPut s --value_file nahradí hodnotu v jednom kroku a ConfigDel nejprve znemožní, aby zůstal zastaralý nebo poškozený záznam. Před začátkem si uložte kopii pracovního skriptu mimo adresář se skripty.
./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 startsacli start aplikuje změněnou konfiguraci na interní služby, a to je to, co uvede nový skript v platnost. Není to totéž jako restart celého stroje nebo démona a nemělo by se to tím nahrazovat, pokud to vaše změna nevyžaduje.
Použijte absolutní cestu k souboru s hodnotou a ověřte, že ji root může přečíst. Cesta, která se vyřeší z vašeho shellu, ale ne z účtu služby, vytvoří uloženou hodnotu, která v ConfigGet vypadá správně a selže při prvním přihlášení. Zkontrolujte uložený výsledek ještě jednou po sacli start, ne před ním.
Rozsah modulu, nebo pro každé připojení: kam dotaz patří
Python spouští příkazy na úrovni modulu jednou, při načtení skriptu. Dotaz do databáze napsaný na začátku souboru proto čte tabulku při načtení a tento výsledek si drží pro každé další připojení. To je druhý důvod, proč se úprava zdá neúčinná: kód se spouští, ale ne ve chvíli, kterou očekáváte.
Umístěte dotaz dovnitř obslužné rutiny post_auth, aby se spouštěl při každém ověření. Zachovejte dokumentovaný podpis, upravte výsledek ověření, který rutina dostává, a vraťte stejný objekt místo holého čísla.
Práci se připojením držte také uvnitř rutiny. Připojení otevřené při importu může server uzavřít dřív, než se přihlásí první uživatel, a výsledná chyba vypadá jako odmítnuté přihlašovací údaje, nikoli jako rozbitý skript.
Dvě cesty odmítnutí, jeden vlastník
Pokud je rozhodnutí místní dotaz, výsledek vlastní rutina v Pythonu. Pokud jde o externí kontrolu přes HTTP, nechte odpověď nést návratový kód příkazu: obal, který skončí nenulovým kódem, přihlášení odmítne a stav posledního příkazu se stane stavem skriptu bez výslovného exit.
Držte tajemství mimo seznam procesů. Soubor čitelný pro root nebo hodnota prostředí předaná službou je bezpečnější než argument, který může kterýkoli místní uživatel přečíst z ps. Před voláním připněte koncový bod do proměnné, aby překlep selhal při konfiguraci, a ne během něčího přihlášení. Tajemství obměňujte stejně jako každé jiné přihlašovací údaje.
Zvolte jednoho vlastníka pro každou kontrolu. Skript, který se dotazuje databáze i volá službu HTTP, potřebuje deklarované pravidlo priority pro případ, že se obojí rozchází, jinak důvod odmítnutí v logu nebude odpovídat tomu, co se řeklo uživateli.
Nasaďte to bez uzamčení správce
Dvě pojistky dělají změnu vratnou: druhý účet správce, který nezávisí na skriptu, a známá dobrá kopie uložená mimo adresář se skripty. Změnu nasaďte v servisním okně a potom před odpojením sledujte jedno zkušební přihlášení a jedno záměrné odmítnutí. Pokud log ukáže syntaktickou chybu místo rozhodnutí o ověření, uložený skript je rozbitý a každé přihlášení selže.
Dvě podmínky říkají počkejte: nemůžete přečíst soubor s hodnotou jako root, nebo nemáte druhou cestu do administračního rozhraní. Obě mění malou změnu v uzamčení a ani jedna nestojí za test na produkčním serveru na konci dne. Dokumentace Access Server pokrývá rozhraní post-auth a jeho podporovaná pole.