Perl CGI - nem azt csinálja, amit kell-

Szkriptek: Python, Perl, Bash, ...

Sziasztok,
vége felé haladok a perl könyvnek, eddig sikeresen végigcsináltam a gyakorlatokat, de ez most kifogott rajtam.
Szeretnék építő jellegű segítséget kérni (hol szúrtam el, hogy jöttél rá, hogyan javítsam ki) és nem egy <300 byte-ba bezsúfolt hatékony teljesen új kódot.
A feladat ez volt:
Írjunk CGI vendégkönyvet, amely lehetővé teszi, hogy a felhasználók egysoros megjegyzéseket fűzzenek a weboldalhoz.
Működik, de rosszul.
Minden bejegyzést rögzít a vendégkönyvben, de csak mindem 2-at írja ki az oldalon. Miért?

A 498_4.txt lenne a vendégkönyv, a 498_4.pl pedig amit itt látsz.

  • 1860 megtekintés

( uid_7086 | 2018. 03. 20., k – 15:38 )

A $input = <MEGJEGYZES>; miatt.
Egyik olvasás a while-ban, másik meg itt. Helyette $input = $_; kellene, ha mindenáron nevesíteni akarod a $_ változót.

Ahogy a kolléga mondja, de ha ennyiből nem volna világos: a while(<MEGJEGYZES>) jelentése nem (csak) annyi, hogy "amíg a MEGJEGYZES azonosítóval jelzett fájl olvasható", hanem mellékhatásként az adott helyen konkrét sor beolvasása meg is történik a $_ nevű automatikus változóba - ezért a műveletért semmit sem kell tenned pluszban.

Azáltal, hogy a $_-ban szereplő sort nem használod fel, hanem egy explicit nevű változóba olvasol egy sort (a következőt!), és csak azt írod ki, minden páratlan sorszámú sorod kimarad a megjelenítésből.

( kikuchiyo | 2018. 03. 21., sze – 00:50 )

Építő jellegű segítség következik:

miféle "perl könyv" az, amiből te 2018-ban (HTML-t kódból generáló, inputot ellenőrzés nélkül lokális fájlba kiíró) CGI-t akarsz tanulni? Javaslom, használd a továbbiakban éknek az asztal lába alá, és keress egy olyan könyvet, amit ebben az évezredben írtak. Például: http://modernperlbooks.com/books/modern_perl_2014/

Ha kifejezetten a perles webfejlesztés érdekel, akkor a PSGI, Catalyst, Dancer2 kulcsszavaknak nézz utána.

A CGI-t manapság legfeljebb annyira érdemes megtanulni, hogy felismerd, ha találkozol vele, és tudd, hogy kell lecserélni valami korszerűbb megoldásra.

HTML-t kódból generáló, inputot ellenőrzés nélkül lokális fájlba kiíró

visszaolvasva tényleg rosszul hangzik, de érdekelne bővebben a véleményed.
Az input formai ellenőrzése valóban lemaradt, de csak, mert most nem ez volt a lényeg.
Talán valamiféle SQL injection-hoz hasonlóra gondoltál? Egyáltalán van ennek perl megfelelője?
Lokális fájlba írás pedig mehet a felmérés idejére létrehozott külön partícióra, ha az megtelne egy túlbuzgó kínai hacker miatt, nem vágná haza a teljes webszolgáltatást.
Talán egy edquota a nobody-nak és akkor a nagios sem fog kiverni az ágyból éjjel 2-kor.

Igazából nem a perles webfejlesztés érdekel, csak a CGI is része volt a könyvnek és nem akartam kihagyni :)
Azaz lett volna egy házon belüli felmérés, csak egy rövid időre kellett volna a szerverre tenni és persze hivatkozás nélkül, link csak az érintetteknek, de akkor még nem tartottam itt, úgyhogy google űrlap ett belőle.
Azért kíváncsi lettem volna, hogyan fut. Mivel iskola vagyunk, a kollegák biztosan 1 időpontban (2 tanóra között) töltötték volna ki, és megnéztem volna, hogy ha egyszerre kattannak a küldés gombra, akkor a fájlírást puffereléssel oldja meg vagy "or die" lép életbe?

Ha most ugyanúgy 1-2 bemeneti adat alapján pár sornyi kimenetet kellene produkálnom böngésző-only@intranet felhasználóknak, mint 20 évvel ezelőtt, és ilyen "riportból" kéne 30, ma sem kezdenék el ehhez olyan eszközt piszkálni, aminek a tanulási görbéje a hello worldig hosszabb, mint 30 CGI-szkript összetaknyolása.
Nincs az a divat, ami annyit megér.

Én meg már ilyenhez sem nyúlnék a CGI-hez.

Ott van helyette pl. a Dancer2, az ilyen minimális oneshot izékre pont jó, a Hello Worldhoz pont semennyit se kell tanulni hozzá, mert tud kulcsrakész project skeletont gyártani neked egy paranccsal, amiben átírod a szöveget és kész, ugyanakkor adottak a továbbfejlesztési lehetőségek, mert minimális efforttal ad neked session-kezelést, templatelést, route paramétereket meg amit akarsz.

Azért javasoltam, hogy ne elavult könyvből tanulj, mert így rossz szokásokat szedsz fel, és később nehezen fogsz tőlük megszabadulni.

A -w kapcsolón, a kódba begyógyított HTML-darabokon, a open(IRAS, ">>$megjegyzes") stílusú fájlmegnyitáson és úgy általában a CGI-n nem divatból, jókedvében lépett túl a szakma, hanem jó okkal. Ilyen kis példánál szőrszálhasogatásnak tűnhet ezekbe belekötni, de a nagyobb, sok modulból álló kódoknál már igenis számítanak.

Talán valamiféle SQL injection-hoz hasonlóra gondoltál? Egyáltalán van ennek perl megfelelője?

Az nem perl-specifikus, hogy ha bármiféle ellenőrzés és szűrés nélkül elmented az user input, aztán úgy, ahogy van, beleírod egy HTML közepébe, akkor azzal szarvashibát vétesz.
Gondold meg, mi történik, ha valaki egy pornóképre mutató <image> taget másol be a text inputmeződbe? Vagy egy <script> taget, benne akármilyen ártalmas Javascript kóddal? A kulcsszó a xss vulnerability, ez annak a legotrombább, legprimitívebb változata.

A CGI-vel van még egy (amúgy sok...) gond: a param metódusa, amivel a paraméter értékét szeded ki a kérésből, lista kontextusban több értéket is visszaad, ha a paraméter többször is szerepelt a kérésben. Ez veszélyes, ha például egy hashet populálsz a paraméterekből, lásd https://metacpan.org/pod/distribution/CGI/lib/CGI.pod#Fetching-the-valu… . A te kódodban pont nincs jelentősége, de élesben előfordult már (pl. a Bugzillánál asszem).

Lokális fájlba írás pedig mehet a felmérés idejére létrehozott külön partícióra, ha az megtelne egy túlbuzgó kínai hacker miatt

Ez lenne a legutolsó, amiből bajod lenne. Mivel a programod minden egyes kérésnél újraolvassa a teljes fájlt (ráadásul soronként), már jóval azelőtt "hazavágná vele a teljes webszolgáltatást" a hacker, hogy betelne a tárhely.

De látod, az elavult forrásból felszedett magabiztos féltudás birtokában már vannak elképzeléseid, hogy az ablak réseit hogyan tömd be, miközben a pajtaajtó tágra van nyitva.

Mivel iskola vagyunk, a kollegák biztosan 1 időpontban (2 tanóra között) töltötték volna ki, és megnéztem volna, hogy ha egyszerre kattannak a küldés gombra, akkor a fájlírást puffereléssel oldja meg vagy "or die" lép életbe?

Miért kéne meghalnia? Több folyamat is megnyithatja ugyanazt a fájlt írásra, olvasásra egyaránt. Az, hogy ilyenkor mi kerül bele és mit fogsz kiolvasni belőle, esetleges.

A minimális példaprogramod csak egy alkalommal ír a fájl végére, így az igen kevéssé valószínű, hogy két kérésből származó írás összekeveredik, de az már simán lehet, hogy amíg az egyik folyamat olvassa a (z időközben nagyra nőtt) fájlt, addig egy másik beleír a végére.

Ezen a fájl lockolásával (perldoc -f flock) lehet segíteni, de akkor meg egyszerre egy kérést szolgál ki a programod, a többi addig blokkol, amíg az egy író nem végzett vele.

Nem ördögtől való ilyen helyi flat fájlt használni, csak érdemes tisztában lenni a limitációkkal.