Access Server игнорише post_auth скрипту коју сте уредили на диску
Уређивање датотеке post_auth на диску не чини ништа: Access Server извршава копију из своје конфигурационе базе података. Пратите пут одлуке и sacli наредбе.
Уређена mac.py која ништа не мења уобичајен је први симптом. Датотека на диску није оно што Access Server извршава; сервис за аутентификацију учитава скрипту из конфигурационе базе података сервера, и управо та сачувана копија одлучује о пријави. Док се сачувана вредност не замени, сваки тест доказује само то да стара скрипта још ради.
Посао одређују три услова: да ли је вредност икада уписана у конфигурациону базу, да ли је сервису наређено да је поново учита, и да ли се измењени код заиста извршава при свакој вези. Сваки има другачији симптом, а поправљање погрешног троши сервисни прозор.
Датотека је извор, а не покренута копија
Access Server држи post-auth скрипту под кључем auth.module.post_auth_script. Уређивање датотеке ажурира само вашу радну копију. Демон чита сачувану вредност, па промена остаје невидљива док не избришете стари запис и не ставите нову датотеку на његово место. Та сачувана вредност једина је копија коју сервис за аутентификацију прегледа.
Прочитајте је пре него што је промените. Ако се већ поклапа са датотеком коју сте уредили, проблем није у складиштењу и пређите на питање обима. Ако показује старију верзију, промена није стигла до сервиса.
./sacli -k auth.module.post_auth_script ConfigGetЗамените сачувану копију, па је примените
Брисање пре уписа није украс. ConfigPut са --value_file замењује вредност у једном кораку, а ConfigDel прво чини немогућим да заостане застарео или оштећен запис. Сачувајте копију радне скрипте изван директоријума скрипти пре него што почнете.
./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 примењује измењену конфигурацију на унутрашње сервисе, и то је оно што нову скрипту ставља на снагу. То није исто као поновно покретање целог рачунара или демона, и не треба то замењивати тиме осим ако ваша промена то захтева.
Користите апсолутну путању за датотеку вредности и потврдите да root може да је чита. Путања која се разрешава из вашег шела али не из налога сервиса даје сачувану вредност која изгледа исправно у ConfigGet и пада при првој пријави. Проверите сачувани резултат још једном након sacli start, не пре.
Обим модула или по вези: где припада упит
Python извршава наредбе на нивоу модула једном, када се скрипта учита. Зато упит према бази написан на врху датотеке чита табелу при учитавању и задржава тај одговор за сваку следећу везу. То је други разлог зашто промена изгледа као да не ради: код се извршава, али не када очекујете.
Ставите упит унутар руковаоца post_auth да се извршава за сваку аутентификацију. Задржите документовани потпис, прилагодите резултат аутентификације који руковалац прима и вратите исти објекат уместо голог броја.
Држите и управљање везом унутар руковаоца. Веза отворена при увозу може бити затворена од стране сервера пре прве пријаве корисника, а настала грешка изгледа као одбијене акредитиве, а не као покварена скрипта.
Два пута одбијања, један власник
Ако је одлука локални упит, резултатом управља Python руковалац. Ако је спољна HTTP провера, нека статус излаза наредбе носи одговор: омотач који излази са ненултим кодом одбија пријаву, а статус последње наредбе постаје статус скрипте без изричитог exit.
Држите тајну изван листе процеса. Датотека читљива за root или вредност окружења коју сервис прослеђује сигурнија је од аргумента који сваки локални корисник може прочитати из ps. Причврстите крајњу тачку у променљиву пре позива, да грешка у куцању падне у време конфигурације, а не током нечије пријаве. Ротирајте ту тајну као и сваку другу акредитиву.
Изаберите једног власника по провери. Скрипта која и пита базу и позива HTTP сервис треба изричито правило приоритета за случај када се њих двоје не слажу, иначе разлог одбијања у дневнику неће одговарати ономе што је кориснику речено.
Примените то без закључавања администратора
Две заштите чине промену реверзибилном: други админ налог који не зависи од скрипте, и позната добра копија чувана изван директоријума скрипти. Примените промену у сервисном прозору, па посматрајте једну пробну пријаву и једно намерно одбијање пре него што се одспојите. Ако дневник покаже синтаксну грешку уместо одлуке о аутентификацији, сачувана скрипта је покварена и свака пријава ће пасти.
Два услова кажу сачекај: не можете прочитати датотеку вредности као root, или немате други пут до админ интерфејса. Оба претварају малу промену у закључавање, и ниједно није вредно тестирања на продукционом серверу на крају дана. Документација Access Server покрива post-auth интерфејс и његова подржана поља.