Redaktita mac.py, kiu ŝanĝas nenion, estas la kutima unua simptomo. La dosiero sur la disko ne estas tio, kion plenumas Access Server; la aŭtentiga servo ŝargas la skripton el la agorda datumbazo de la servilo, kaj ĝuste tiu konservita kopio decidas pri ensaluto. Ĝis la konservita valoro estos anstataŭigita, ĉiu testo pruvas nur, ke la malnova skripto ankoraŭ funkcias.

Tri kondiĉoj decidas la laboron: ĉu la valoro iam estis metita en la agordan datumbazon, ĉu la servo ricevis ordonon reŝargi ĝin, kaj ĉu la kodo, kiun vi ŝanĝis, efektive ruliĝas ĉe ĉiu konekto. Ĉiu havas alian simptomon, kaj ripari la malĝustan malŝparas prizorgan fenestron.

La dosiero estas fonto, ne la kuranta kopio

Access Server tenas la post-auth-skripton sub la ŝlosilo auth.module.post_auth_script. Redakti la dosieron ĝisdatigas nur vian laboran kopion. La demono legas la konservitan valoron, do la ŝanĝo restas nevidebla ĝis vi forigos la malnovan eron kaj metos la novan dosieron en ĝian lokon. Tiu konservita valoro estas la sola kopio, kiun konsultas la aŭtentiga servo.

Legu ĝin antaŭ ol ŝanĝi ĝin. Se ĝi jam kongruas kun la dosiero, kiun vi redaktis, la problemo ne estas la konservado kaj vi devas salti al la demando pri amplekso. Se ĝi montras pli malnovan version, la ŝanĝo neniam atingis la servon.

./sacli -k auth.module.post_auth_script ConfigGet

Anstataŭigu la konservitan kopion, poste apliku ĝin

Forigi antaŭ ol skribi ne estas ornamaĵo. ConfigPut kun --value_file anstataŭigas la valoron en unu paŝo, kaj ConfigDel unue malebligas lasi malnovan aŭ difektitan eron. Konservu kopion de la funkcianta skripto ekster la skripta dosierujo antaŭ ol komenci.

./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 aplikas la ŝanĝitan agordon al la internaj servoj, kaj tio igas la novan skripton validi. Ĝi ne samas al restartigo de la tuta maŝino aŭ de la demono, kaj oni ne anstataŭigu ĝin per tio, krom se via ŝanĝo tion postulas.

Uzu absoluton vojon por la valora dosiero kaj konfirmu, ke root povas legi ĝin. Vojo solvita el via ŝelo sed ne el la servo-konto produktas konservitan valoron, kiu aspektas ĝusta en ConfigGet kaj malsukcesas ĉe la unua ensaluto. Kontrolu la konservitan rezulton ankoraŭfoje post sacli start, ne antaŭe.

Modula amplekso aŭ po konekto: kie apartenas la peto

Python plenumas modulnivelajn asertojn unufoje, kiam la skripto ŝargiĝas. Datumbaza peto skribita supre en la dosiero tial legas la tabelon dum ŝargado kaj konservas tiun respondon por ĉiu posta konekto. Tio estas la dua kialo, kial ŝanĝo ŝajnas fari nenion: la kodo ruliĝas, sed ne kiam vi atendas.

Metu la peton ene de la post_auth-traktilo, por ke ĝi ruliĝu ĉe ĉiu aŭtentigo. Konservu la dokumentitan subskribon, adaptu la aŭtentigan rezulton, kiun ricevas la traktilo, kaj redonu tiun saman objekton anstataŭ nudan nombron.

Tenadu ankaŭ la konektan prizorgadon ene de la traktilo. Konekto malfermita ĉe importo povas esti fermita de la servilo antaŭ ol la unua uzanto ensalutu, kaj la rezulta eraro aspektas kiel rifuzitaj akreditaĵoj anstataŭ rompita skripto.

Du rifuzaj vojoj, unu posedanto

Se la decido estas loka peto, la Python-traktilo posedas la rezulton. Se ĝi estas ekstera HTTP-kontrolo, lasu la eliran staton de la komando porti la respondon: ĉirkaŭilo, kiu eliras kun ne-nula valoro, rifuzas la ensaluton, kaj la stato de la lasta komando fariĝas la stato de la skripto sen eksplicita exit.

Tenadu la sekreton ekster la proceza listo. Dosiero legebla de root aŭ media valoro transdonita de la servo estas pli sekura ol argumento, kiun iu ajn loka uzanto povas legi el ps. Fiksu la finpunkton en variablo antaŭ la voko, por ke tajperaro malsukcesu ĉe agordado, ne dum ies ensaluto. Rotaciu tiun sekreton same kiel ajnan alian akreditaĵon.

Elektu unu posedanton por ĉiu kontrolo. Skripto, kiu kaj pridemandas la datumbazon kaj vokas HTTP-servon, bezonas deklaran prioritatregulon por la kazo, kiam la du malkongruas, alie la rifuza kaŭzo en la protokolo ne kongruos kun tio, kio estis dirita al la uzanto.

Apliku ĝin sen ŝlosi la administranton

Du sekurigiloj igas la ŝanĝon reigebla: dua administra konto, kiu ne dependas de la skripto, kaj konata bona kopio tenata ekster la skripta dosierujo. Apliku la ŝanĝon en prizorga fenestro, poste observu unu testan ensaluton kaj unu intencan rifuzon antaŭ ol malkonektiĝi. Se la protokolo montras sintaksan eraron anstataŭ aŭtentigan decidon, la konservita skripto estas rompita kaj ĉiu ensaluto malsukcesos.

Du kondiĉoj diras atendu: vi ne povas legi la valoran dosieron kiel root, aŭ vi ne havas duan vojon en la administran interfacon. Ambaŭ transformas malgrandan ŝanĝon en ŝloson, kaj neniu el ili indas esti testata sur produktada servilo je la fino de la tago. La dokumentaro de Access Server kovras la post-auth-interfacon kaj ĝiajn subtenatajn kampojn.

Rilataj artikoloj