’n Gewysigde mac.py wat niks verander nie, is die gewone eerste simptoom. Die leer op skyf is nie wat Access Server uitvoer nie; die verifikasiediens laai die skrip uit die bediener se konfigurasiedatabasis, en daardie gestoorde kopie is wat ’n aanmelding besluit. Totdat die gestoorde waarde vervang word, bewys elke toets net dat die ou skrip nog werk.

Drie toestande bepaal die werk: of die waarde ooit in die konfigurasiedatabasis gesit is, of die diens beveel is om dit te herlaai, en of die kode wat jy verander het werklik per verbinding loop. Elkeen het ’n ander simptoom, en om die verkeerde een reg te maak mors ’n onderhoudsvenster.

Die leer is ’n bron, nie die lopende kopie nie

Access Server hou die post-auth-skrip onder die sleutel auth.module.post_auth_script. Om die leer te wysig, werk jou werkkopie by en niks anders nie. Die daemon lees die gestoorde waarde, so die wysiging bly onsigbaar totdat jy die ou inskrywing verwyder en die nuwe leer in sy plek sit. Daardie gestoorde waarde is die enigste kopie wat die verifikasiediens raadpleeg.

Lees dit voordat jy dit verander. As dit reeds ooreenstem met die leer wat jy gewysig het, is die probleem nie die stoor nie en moet jy na die vraag oor die omvang spring. As dit ’n ouer weergawe wys, het die wysiging nooit die diens bereik nie.

./sacli -k auth.module.post_auth_script ConfigGet

Vervang die gestoorde kopie en pas dit dan toe

Om voor die skryf te verwyder is nie versiering nie. ConfigPut met --value_file vervang die waarde in een stap, en ConfigDel eerste maak dit onmoontlik om ’n verouderde of korrupte inskrywing agter te laat. Hou ’n kopie van die werkende skrip buite die skrips-gids voordat jy begin.

./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 pas die veranderde konfigurasie op die interne dienste toe, en dit is wat die nuwe skrip laat werk. Dit is nie dieselfde as om die hele masjien of die daemon te herbegin nie, en dit moet nie daardeur vervang word nie, tensy die verandering wat jy maak dit vereis.

Gebruik ’n absolute pad vir die waardeleer en bevestig dat root dit kan lees. ’n pad wat vanuit jou dop opgelos word maar nie vanuit die diensrekening nie, lewer ’n gestoorde waarde wat in ConfigGet reg lyk en by die eerste aanmelding faal. Kyk na sacli start weer na die gestoorde resultaat, nie voor dit nie.

Module-omvang of per verbinding: waar die soektog hoort

Python voer modulevlak-stellings een keer uit, wanneer die skrip gelaai word. ’n databasisnavraag wat bo in die leer geskryf is, lees dus die tabel by laaityd en hou daardie antwoord vir elke latere verbinding. Dit is die tweede rede waarom ’n wysiging lyk of dit niks doen nie: die kode loop, maar nie wanneer jy verwag nie.

Sit die navraag binne die post_auth-hanteerder sodat dit vir elke verifikasie uitgevoer word. Hou die gedokumenteerde handtekening, pas die verifikasiestatus aan wat die hanteerder ontvang, en gee daardie selfde objek terug eerder as ’n kaal getal.

Hou ook die verbindingshantering binne die hanteerder. ’n verbinding wat by invoer oopgemaak word, kan deur die bediener gesluit word voor die eerste gebruiker aanmeld, en die gevolglike fout lyk soos ’n verwerpte geloofsbrief eerder as ’n gebreekte skrip.

Twee verwerp-paaie, een eienaar

As die besluit ’n plaaslike soektog is, besit die Python-hanteerder die resultaat. As dit ’n eksterne HTTP-kontrole is, laat die opdrag se uittredestatus die antwoord dra: ’n omhulsel wat nie-nul uitgaan, verwerp die aanmelding, en die laaste opdrag se status word die skrip se status sonder ’n eksplisiete exit.

Hou die geheim uit die proselys. ’n root-leesbare leer of ’n omgewingswaarde wat deur die diens deurgegee word, is veiliger as ’n argument wat enige plaaslike gebruiker uit ps kan lees. Pen die eindpunt in ’n veranderlike vas voor die oproep, sodat ’n tikfout by konfigurasietyd faal eerder as tydens iemand se aanmelding. Roteer daardie geheim op dieselfde manier as enige ander geloofsbrief.

Kies een eienaar per kontrole. ’n skrip wat beide die databasis navra en ’n HTTP-diens oproep, het ’n verklaarde voorrangreel nodig vir die geval waar die twee verskil, anders sal die verwerpingsrede in die log nie ooreenstem met wat aan die gebruiker gese is nie.

Pas dit toe sonder om die administrateur uit te sluit

Twee veiligheidsmaatreels maak die verandering omkeerbaar: ’n tweede admin-rekening wat nie van die skrip afhang nie, en ’n bekende-goeie kopie wat buite die skrips-gids gehou word. Pas die verandering in ’n onderhoudsvenster toe en kyk dan na een toetsaanmelding en een doelbewuste verwerping voordat jy ontkoppel. As die log ’n sintaksfout wys eerder as ’n verifikasiestatus, is die gestoorde skrip stukkend en elke aanmelding sal faal.

Twee toestande se wag: jy kan die waardeleer nie as root lees nie, of jy het geen tweede weg na die admin-koppelvlak nie. Albei maak ’n klein verandering ’n uitsluiting, en nie een is werd om dit aan die einde van die dag op ’n produksiebediener te toets nie. Die Access Server-dokumentasie dek die post-auth-koppelvlak en sy ondersteunde velde.

Verwante artikels