OpenVPN скрипта auth-user-pass-verify: правилен излезен код

OpenVPN дејствува врз точно еден излез од скриптата за најава: излезниот статус. Сѐ друго што ја прави скриптата е декорација. Куката може да стигне до вистинскиот проверувач, да го анализира одговорот и да испечати пријателски ред, а притоа да врати статус што значи спротивно од она што авторот го намерил. Прочитајте го договорот прво и напишете го адаптерот околу него, и целата таа класа грешки исчезнува.

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

Трите статуси што куката може да ги врати

auth-user-pass-verify за прирачникот за OpenVPN 2.6 го дефинира излезниот код 0 како прифаќање, 1 како одбивање и 2 како одложена автентикација. Тоа се единствените три одговори што ги разбира серверот, и секој има различно влијание врз врската. Скриптата што излегува со статусот на нејзината последна наредба всушност дозволила повик за дневник или чекор за чистење да гласа. Запишете го статусот експлицитно во секоја гранка, вклучително и во гранките што никогаш не стигнале до проверувачот.

Успехот на HTTP и успехот на автентикацијата се одделни слоеви, и нивното мешање е најчестиот начин оваа кука да погреши. Одговорот 202 значи дека барањето е прифатено за обработка, а не дека лозинката е проверена. Дефинирајте го очекуваниот статус, формата на одговорот и конечната пресуда од API договорот што ви е даден, и не измислувајте име на поле затоа што изгледа веродостојно.

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

Читајте ја датотеката со акредитиви точно како што е напишана

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

Држете ги сопствените акредитиви на проверувачот одвоени од корисничките: тие и припаѓаат на интеграцијата со портата, живеат во складиштето за тајни на платформата и бараат само дозвола за проверка, па затоа не се доказ дека одредено лице се автентицирало. Не дозволувајте куката да стане и втор проверувач на лозинки. Рачното препишување на споредба на хеш не станува безбедно со оптимизирање на циклусот, а одржуван проверувач веќе ја разбира солената и скапа шема на складиштето на сметки.

Одлучете што значи некласифициран одговор

Временските ограничувања, транспортните грешки, деформираните одговори и недостапниот backend делат една особина: ниту еден од нив не е позитивна проверка. Куката треба да се затвори при секој од нив и да запише причина врз која операторот може да дејствува. Таа причина и припаѓа на заштитен дневник, а не на порака вратена на лицето што се обидува да се поврзе.

Бидете исто толку внимателни со патеките што воопшто не стигнуваат до проверувачот. Недостапна конфигурациска вредност, нечитлива тајна или неинсталирана зависност треба да дадат одбивање со посебен оперативен маркер наместо случајно прифаќање. Тестирајте ги тие гранки со отстранување на зависноста во лабораторија, наместо да размислувате за нив. Каде што неуспехот да се логира може да го промени излезниот статус, логирањето станало дел од одлуката и мора да се направи безопасно.

Конфигурацијата на серверот е важна и овде: скриптите дефинирани од корисникот се почитуваат само кога конфигурацијата што работи ги дозволува на потребното ниво на безбедност, а таа поставка е свесен избор, а не стандардна вредност што треба да се подигне.

Проверете ја пресудата, а не испечатениот ред

Изградете тест што директно го проверува излезниот статус. Напишете примерна датотека со акредитиви, извршете ја куката врз неа со познато добра и познато лоша сметка и читајте го статусот што го пријавува школката, а не текстот што го печати скриптата. Таа единствена проверка ги фаќа повеќето грешки во договорот пред клиентот воопшто да се поврзе.

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

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