Access Server ја игнорира post_auth скриптата што ја уредивте на дискот

Уредена 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 start

sacli start ја применува сменетата конфигурација врз внатрешните служби, и тоа е она што ја става новата скрипта во сила. Тоа не е исто како рестартирање на целата машина или на демонот, и не треба да се заменува со тоа освен ако вашата промена го бара.

Користете апсолутна патека за датотеката со вредност и потврдете дека root може да ја чита. Патеката што се решава од вашата обвивка, но не од сметката на службата, дава зачувана вредност што изгледа исправна во ConfigGet и не успева при првата најава. Проверете го зачуваниот резултат уште еднаш по sacli start, не пред тоа.

Опфат на модулот или по врска: каде припаѓа барањето

Python ги извршува изразите на ниво на модул еднаш, при вчитувањето на скриптата. Затоа барањето до базата напишано на врвот од датотеката ја чита табелата при вчитувањето и го задржува тој одговор за секоја следна врска. Тоа е втората причина зошто промената изгледа како ништо да не прави: кодот се извршува, но не кога очекувате.

Ставете го барањето внатре во ракувачот post_auth за да се извршува при секоја автентикација. Задржете го документираниот потпис, прилагодете го резултатот од автентикацијата што го добива ракувачот и вратете го истиот објект наместо гол број.

Држете го и управувањето со врската внатре во ракувачот. Врската отворена при вчитување може да биде затворена од серверот пред првиот корисник да се најави, а грешката што произлегува изгледа како одбиени акредитиви, а не како скршена скрипта.

Две патеки на одбивање, еден сопственик

Ако одлуката е локално барање, резултатот му припаѓа на Python ракувачот. Ако е надворешна HTTP проверка, нека статусот на излезот на наредбата го носи одговорот: обвивка што излегува со код различен од нула ја одбива најавата, а статусот на последната наредба станува статус на скриптата без експлицитен exit.

Држете ја тајната надвор од списокот процеси. Датотека читлива за root или вредност од околината што ја пренесува службата е побезбедна од аргумент што секој локален корисник може да го прочита од ps. Прикачете ја крајната точка во променлива пред повикот, за печатна грешка да не успее при конфигурацијата, а не за време на нечија најава. Ротирајте ја таа тајна како и секои други акредитиви.

Изберете еден сопственик за секоја проверка. Скрипта што и ја прашува базата и повикува HTTP служба бара објавено правило за приоритет за случајот кога двете се разликуваат, инаку причината за одбивањето во дневникот нема да се совпадне со она што му е кажано на корисникот.

Применете го без да го заклучите администраторот

Две заштити ја прават промената повратна: втора администраторска сметка што не зависи од скриптата, и позната добра копија чувана надвор од директориумот за скрипти. Применете ја промената во сервисен прозорец, потоа пред да се исклучите набљудувајте една пробна најава и едно намерно одбивање. Ако дневникот покажува синтаксна грешка наместо одлука за автентикација, зачуваната скрипта е скршена и секоја најава ќе не успее.

Два услова велат почекајте: не можете да ја прочитате датотеката со вредност како root, или немате втор пат до администраторскиот интерфејс. Двете претвораат мала промена во заклучување, и ниту едно не вреди тестирање на продукциски сервер на крајот од денот. Документацијата на Access Server го покрива post-auth интерфејсот и неговите поддржани полиња.