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 і падтрымоўваныя палі.