Access Server ignoruje skrypt post_auth, który edytowałeś na dysku

Edytowany mac.py, który niczego nie zmienia, to zwykły pierwszy objaw. Plik na dysku nie jest tym, co wykonuje Access Server; usługa uwierzytelniania wczytuje skrypt z bazy konfiguracji serwera i właśnie ta zapisana kopia decyduje o logowaniu. Dopóki zapisana wartość nie zostanie zastąpiona, każdy test dowodzi tylko, że stary skrypt nadal działa.

Pracę rozstrzygają trzy warunki: czy wartość kiedykolwiek trafiła do bazy konfiguracji, czy usługa dostała polecenie ponownego wczytania jej, oraz czy zmieniony kod naprawdę wykonuje się przy każdym połączeniu. Każdy ma inny objaw, a naprawianie niewłaściwego marnuje okno serwisowe.

Plik jest źródłem, nie kopią roboczą

Access Server trzyma skrypt post-auth pod kluczem auth.module.post_auth_script. Edycja pliku aktualizuje tylko twoją kopię roboczą. Demon czyta zapisaną wartość, więc zmiana pozostaje niewidoczna, dopóki nie usuniesz starego wpisu i nie wstawisz nowego pliku na jego miejsce. Ta zapisana wartość to jedyna kopia, którą sprawdza usługa uwierzytelniania.

Przeczytaj ją, zanim ją zmienisz. Jeśli już odpowiada edytowanemu plikowi, problem nie leży w przechowywaniu i przejdź do pytania o zakres. Jeśli pokazuje starszą wersję, zmiana nigdy nie dotarła do usługi.

./sacli -k auth.module.post_auth_script ConfigGet

Zastąp zapisaną kopię, potem ją zastosuj

Usuwanie przed zapisem nie jest ozdobą. ConfigPut z --value_file zastępuje wartość w jednym kroku, a ConfigDel najpierw czyni niemożliwym pozostawienie nieaktualnego lub uszkodzonego wpisu. Przed rozpoczęciem zachowaj kopię działającego skryptu poza katalogiem skryptów.

./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 stosuje zmienioną konfigurację do usług wewnętrznych i to właśnie sprawia, że nowy skrypt zaczyna obowiązywać. To nie to samo co restart całej maszyny lub demona i nie należy tego tym zastępować, chyba że twoja zmiana tego wymaga.

Użyj ścieżki bezwzględnej do pliku wartości i potwierdź, że root może go odczytać. Ścieżka, która rozwiązuje się z twojej powłoki, ale nie z konta usługi, daje zapisaną wartość, która wygląda poprawnie w ConfigGet i zawodzi przy pierwszym logowaniu. Sprawdź zapisany wynik jeszcze raz po sacli start, nie przed.

Zakres modułu czy na połączenie: gdzie należy zapytanie

Python wykonuje instrukcje na poziomie modułu raz, przy wczytaniu skryptu. Dlatego zapytanie do bazy napisane na górze pliku odczytuje tabelę w chwili wczytania i zachowuje tę odpowiedź dla każdego późniejszego połączenia. To drugi powód, dla którego zmiana wydaje się nic nie robić: kod się wykonuje, ale nie wtedy, gdy tego oczekujesz.

Umieść zapytanie w procedurze obsługi post_auth, aby wykonywało się przy każdym uwierzytelnieniu. Zachowaj udokumentowaną sygnaturę, dostosuj wynik uwierzytelnienia otrzymywany przez procedurę i zwróć ten sam obiekt zamiast nagiej liczby.

Także obsługę połączenia trzymaj w procedurze. Połączenie otwarte przy imporcie może zostać zamknięte przez serwer, zanim zaloguje się pierwszy użytkownik, a powstały błąd wygląda jak odrzucone dane logowania, nie jak uszkodzony skrypt.

Dwie ścieżki odmowy, jeden właściciel

Jeśli decyzją jest lokalne zapytanie, wynikiem zarządza procedura Pythona. Jeśli to zewnętrzne sprawdzenie HTTP, pozwól, by status wyjścia polecenia niósł odpowiedź: otoczka kończąca się kodem różnym od zera odrzuca logowanie, a status ostatniego polecenia staje się statusem skryptu bez jawnego exit.

Trzymaj sekret poza listą procesów. Plik czytelny dla roota lub wartość środowiska przekazana przez usługę są bezpieczniejsze niż argument, który każdy lokalny użytkownik może odczytać z ps. Przypnij punkt końcowy do zmiennej przed wywołaniem, aby literówka zawiodła przy konfiguracji, a nie podczas czyjegoś logowania. Rotuj ten sekret tak jak każde inne poświadczenie.

Wybierz jednego właściciela na sprawdzenie. Skrypt, który zarówno pyta bazę, jak i wywołuje usługę HTTP, potrzebuje ogłoszonej reguły pierwszeństwa na wypadek, gdy oba się różnią, inaczej powód odmowy w dzienniku nie będzie zgodny z tym, co powiedziano użytkownikowi.

Zastosuj to bez blokowania administratora

Dwa zabezpieczenia czynią zmianę odwracalną: drugie konto administratora, które nie zależy od skryptu, oraz znana dobra kopia trzymana poza katalogiem skryptów. Zastosuj zmianę w oknie serwisowym, a potem obserwuj jedno logowanie testowe i jedno celowe odrzucenie, zanim się rozłączysz. Jeśli dziennik pokazuje błąd składni zamiast decyzji uwierzytelnienia, zapisany skrypt jest uszkodzony i każde logowanie zawiedzie.

Dwa warunki mówią czekaj: nie możesz odczytać pliku wartości jako root, albo nie masz drugiej drogi do interfejsu administracyjnego. Oba zamieniają małą zmianę w zablokowanie dostępu, a żaden nie jest wart testowania na serwerze produkcyjnym pod koniec dnia. Dokumentacja Access Server omawia interfejs post-auth i obsługiwane przez niego pola.