A InfoWiki wikiből
(uploaded) |
(uploaded) |
||
| 10. sor: | 10. sor: | ||
<path l1="cgi-ea/Nyitolap|Előadás" l2="cgi-ea/Tematika|Vizsga" l3="cgi-ea/Foliak|Fóliák" lx="-" | <path l1="cgi-ea/Nyitolap|Előadás" l2="cgi-ea/Tematika|Vizsga" l3="cgi-ea/Foliak|Fóliák" lx="-" | ||
l4="cgi-gy/Nyitolap|Gyakorlat"/> | l4="cgi-gy/Nyitolap|Gyakorlat"/> | ||
| + | |||
| + | == HTML Form == | ||
| + | |||
| + | A HTML segítségével űrlap (form) írható le, amely a kliens oldali adatbekérés alapvető eszköze. A form mezőit a felhasználó a kliens oldalon kitölti, majd a kitöltött űrlap-adatokat visszatölti a szerverre (''submit'' művelet). | ||
| + | |||
| + | == FORM feldolgozás == | ||
| + | |||
| + | A visszaküldött form mezőket a szerveren fel kell dolgozni. Erre alkalmasak a CGI, FastCGI alkalmazások, illetve amennyiben a webszerver képes az adott scripting nyelven megírt programokat modul szinten futtatni - úgy ezen módszer is működhet. | ||
| + | |||
| + | Jellemző, hogy a visszaküldött mezőkben definiált adatokat valamilyen SQL adatbázisban kell tárolni. Amennyiben az űrlap egy belépési (login) form, úgy ezen mezők alapján a felhasználót hitelesíteni kell (név + jelszó kezelése). A mezők értékei alapján egy új lapot kell generálni friss tartalommal. Amennyiben az űrlapban szereplő adatok minőségével nem vagyunk elégedettek, egy hibaleírás-listát kell visszaküldeni, és a formot is, hogy töltse ki újra. Amennyiben a form adatok rendben vannak, egy pozitív visszajelzéseket tartalmazó dokumentumot kell generálni (belépés/tárolás sikeres). | ||
| + | |||
| + | A form adatok ellenőrzése történhet: | ||
| + | * Kliens oldalon: a böngésző támogatásával a form adatok visszaküldése előtt (jellemzően JavaScript nyelven) | ||
| + | * Szerver oldalon: valamely CGI program segítségével (jellemzően PhP nyelven) | ||
| + | |||
| + | A kliens oldali ellenőrzés kihagyható. A szerver oldali '''SOSEM hagyható ki'''! Hiába küldtünk a formmal el egy kiválóan és alaposan megírt JavaScript programot a kliens oldali ellenőrzéshez, amely meggátolja a hibás adatok szerverre küldését - a szerver sosem hiheti el, hogy a kliens oldali ellenőrzés lefutott, és a kapott adatok hibátlanok! Ennek két oka van: | ||
| + | * A kliens oldali böngészőben a JavaScript futtatása letiltható. Ez esetben a kiválóan és alaposan megírt JavaScriptünk el sem indul. Mindenféle ellenőrzés nélkül kerülnek a szerverre a form adatok. | ||
| + | * A klienstől a szerver felé küldés közben (a JavaScript ellenőrzés után) a küldött adatok manipulálhatók. Mire a szerverre érnek, az adatok megváltoztathatóak (szándékos hack kísérlet) | ||
| + | |||
| + | == HTML Form felépítése == | ||
| + | |||
| + | Amennyiben a HTML dokumentumunkba űrlapot kívánunk elhelyezni, azt a '''form''' elem segítségével kell megtennünk. Ehhez a HTML elemhez (tag) mindíg kell lezáró elemet is írni. Egyetlen HTML dokumentumba több form-t is elhelyezhetünk. Ez esetben mindegyikhez saját visszaküldési gombot (submit button) kell elhelyezni, és aktiválásakor csak az adott submit gombhoz tartozó form adatait küldi vissza. Ez igen zavaró lehet, mivel a felhasználó minden form összes mezőjét kitöltheti, de ezek nagy részét ekkor feleslegesen. | ||
| + | |||
| + | A form mezők esetén minden beviteli elemnek ''nevet'' (name) kell adni. A felküldéskor név-érték párosok kerülnek felküldésre (mintha változó értékadásokat látnánk, pl "nev=lajoska"). Ezért egyrészt minden form elemnek kötelező nevet adni, másrészt ezen neveknek az adott formon belül egyedieknek kell lenni! | ||
| + | |||
| + | A form elem nevét a programozók választják. Nem szokás ékezetes betűket használni, és kifejezetten nem szokás szóközt alkalmazni a form elem nevében. Hagyományosan csak angol ABC betűit (elsősorban kisbetűket), számjegyet, aláhúzást alkalmazunk. | ||
| + | |||
| + | A form elem értéke a felhasználó által kerül kitöltésre. Ebben természetesen már ''vad dolgok'' is előfordulnak (ékezetes betűk, szóköz, különleges karakterek, mint az aposztróf, százalékjel, stb). A HTML szerint ezen nem szokványos karaktereket kódolva kell átküldeni a klienstől a webszerverre, hogy az esetleg jelen lévő kódlap különbségek ne okozzanak zavart. Gondoljunk csak bele, amint egy kínai ügyfél a 'mi a neved' kérdésre a kínai billentyűzettel szerelet laptopján komolyan veszi a kérdést, és beírja. Vizualizáljuk az angol nyelvű linux szerveren futú CGI program zavarát, amint megpróbálja értelmezni! A kódolást (és a webszerven dekódolását) az ''urlencode'' és ''urldecode'' módszerek tárgyalják. | ||
| + | |||
| + | Az űrlap egyik legfontosabb eleme az '''action''', amely megadja, hogy az űrlap adatait hova kell visszaküldeni. Ez jellemzően ugyanazon webszerver egy CGI/FastCGI alkalmazására, vagy scriptjére mutat. Nem gyakori, de lehetséges, hogy a visszaküldés nem ugyanazon web szerverre mutat, mint ahonnan a form maga letöltődött. | ||
| + | |||
| + | <code lang="html"> | ||
| + | <form | ||
| + | action=”http://somesite.com/prog/adduser/index.php” | ||
| + | method="post” | ||
| + | enctype=”...” | ||
| + | accept-charset=”...” | ||
| + | accept=”...” | ||
| + | name=”...” > | ||
| + | .... | ||
| + | </form> | ||
| + | </code> | ||
| + | |||
| + | A másik fontos eleme a '''method''', mely a visszaküldési módszert definiálja. A HTTP protokoll ugyanis kétféle módszert támogat, a '''get''' és '''post''' módot. | ||
| + | |||
| + | A '''get''' mód nem kifejezetten a form mezők visszaküldésére lett kitalálva, de alkalmazható erre is. A '''post''' a gyakoribb módszer. Ez az alapértelmezett módszer is, tehát ha a form fejrészében ezt nem adjuk meg külön, akkor automatikusan a ''post'' módszer lesz alkalmazva. | ||
| + | |||
| + | |||
| + | == POST metódus == | ||
| + | |||
| + | Vizsgáljuk meg mi történik meg, ha a formok esetén általában használt ''post'' metódust választjuk: | ||
| + | |||
| + | <code lang="html"> | ||
| + | <form action=”...” method="post”> | ||
| + | ... | ||
| + | </form> | ||
| + | </code> | ||
| + | |||
| + | Ez esetben a submit (felküldés) gomb hatására a form elemek bekerülnek a HTTP kérés szövegébe (lásd lenti példa): | ||
| + | |||
| + | <code lang="txt"> | ||
| + | POST http://somesite.com/prog/adduser/index.php HTTP/1.1 | ||
| + | PHPSESSID=mlbvlvgs7aqb6ldu4vrfj3ldo2 | ||
| + | Content-Type: application/x-www-form-urlencoded | ||
| + | Content-Length: 233 | ||
| + | fej_sid=11&sid=32&fej_canmodify=false&row_id=0&biz_szam=c111&biz_tipusa=1&datum=2009.12.22& | ||
| + | cel=&partner=Alpinkabel&hatarido=2009.01.12&fokszam=0711&osszeg=32212 | ||
| + | HTTP/1.x 200 OK | ||
| + | </code> | ||
| + | |||
| + | A ''Content-Length'' (tartalom hossza) írja le, hogy 233 byteot használunk el az adatok küldésére. Az adatok ez alatt helyezkednek el. Mindíg név-érték párosokból áll, melyek között a határoló jel az ''et''-jel (& karakter). A ''Content-Type''-ben is jelezve van, hogy amennyiben az értékek speciális karaktereket tartalmaznának, úgy az ''url-encode'' módszer van alkalmazva annak kódolására. A szerver ezt olvasván automatikusan futtatja az ''url-decode'' módot az adatok feldolgozása előtt. | ||
| + | |||
| + | A látványos része a ''post'' beküldésnek, hogy a form adatai a felhasználó elől ''láthatatlan'' módon kerül elküldésre. A submit gombra kattintva a fenti adatküldés megtörténik, a böngészőjében a kiírt link az ''action''-ban szereplő lesz, esetünkben a ''http://somesite.com/prog/adduser/index.php'' kerül kijelzésre. Amennyiben az oldalt újratölti (F5 billentyű, vagy menüből), a legtöbb böngésző megkérdezi, hogy valóban újra akarja-e küldeni a form adatokat a szerverre. Ez veszélyes lehet, hiszen ha a formban egy banki utalást írtunk le, melyben pénzt utaltunk el valahova, újraküldés esetén a szerver értelmezheti azt még egy utalási utasításnak is! | ||
| + | |||
| + | == GET metódus == | ||
| + | |||
| + | A GET módszer esetén a form adatok beküldése nem ilyen ''láthatatlan'', hanem nagyon is látható módon történik meg. A formhoz rendelt ''action'' url egészül ki, ide kerülnek a form adatok. Itt biztosan az ''url-encode'' módszert alkalmazza a böngésző a küldéskor, hiszen a generált url meg kell feleljen a szigorú előírásoknak (nem tartalmazhat pl. szóközt). | ||
| + | |||
| + | <code lang="html"> | ||
| + | <form action=”...” method=”get”> | ||
| + | ... | ||
| + | </form> | ||
| + | </code> | ||
| + | |||
| + | Ez esetben a küldés (submit) után a böngészőben az alábbi link lesz látható: | ||
| + | |||
| + | http://somesite.com/prog/adduser/index.php?fej_sid=11&sid=32&fej_canmodify=false | ||
| + | &row_id=0&biz_szam=c111&biz_tipusa=1&datum=2009.12.22&cel=&partner=Alpinkabel& | ||
| + | hatarido=2009.01.12&fokszam=0711&osszeg=32212 | ||
| + | |||
| + | |||
| + | == POST versus GET == | ||
| + | |||
| + | * A két megoldás egyenértékű funkcionalitást biztosít | ||
| + | * POST metódussal a link "szép" marad | ||
| + | * GET metódussal a link kézzel szerkeszthető a user által (biztonsági rés) | ||
| + | * mindkét esetben manipulálhatóak az adatok küldés előtt (jobb ha tudjuk, bár POST esetén kissé nehezebben) | ||
| + | * A szerver oldalon tudni kell, hogy post vagy get módszerrel lettek küldve az adatok, hiszen az adatok kiolvasása nem ugyanazon módszerrel történik (pl. PhP esetén egyik esetben a $_GET, másik esetben a $_POST tömbbe kerülnek az adatok). | ||
A lap 2009. június 26., 19:18-kori változata
Tartalomjegyzék |
HTML Form
A HTML segítségével űrlap (form) írható le, amely a kliens oldali adatbekérés alapvető eszköze. A form mezőit a felhasználó a kliens oldalon kitölti, majd a kitöltött űrlap-adatokat visszatölti a szerverre (submit művelet).
FORM feldolgozás
A visszaküldött form mezőket a szerveren fel kell dolgozni. Erre alkalmasak a CGI, FastCGI alkalmazások, illetve amennyiben a webszerver képes az adott scripting nyelven megírt programokat modul szinten futtatni - úgy ezen módszer is működhet.
Jellemző, hogy a visszaküldött mezőkben definiált adatokat valamilyen SQL adatbázisban kell tárolni. Amennyiben az űrlap egy belépési (login) form, úgy ezen mezők alapján a felhasználót hitelesíteni kell (név + jelszó kezelése). A mezők értékei alapján egy új lapot kell generálni friss tartalommal. Amennyiben az űrlapban szereplő adatok minőségével nem vagyunk elégedettek, egy hibaleírás-listát kell visszaküldeni, és a formot is, hogy töltse ki újra. Amennyiben a form adatok rendben vannak, egy pozitív visszajelzéseket tartalmazó dokumentumot kell generálni (belépés/tárolás sikeres).
A form adatok ellenőrzése történhet:
- Kliens oldalon: a böngésző támogatásával a form adatok visszaküldése előtt (jellemzően JavaScript nyelven)
- Szerver oldalon: valamely CGI program segítségével (jellemzően PhP nyelven)
A kliens oldali ellenőrzés kihagyható. A szerver oldali SOSEM hagyható ki! Hiába küldtünk a formmal el egy kiválóan és alaposan megírt JavaScript programot a kliens oldali ellenőrzéshez, amely meggátolja a hibás adatok szerverre küldését - a szerver sosem hiheti el, hogy a kliens oldali ellenőrzés lefutott, és a kapott adatok hibátlanok! Ennek két oka van:
- A kliens oldali böngészőben a JavaScript futtatása letiltható. Ez esetben a kiválóan és alaposan megírt JavaScriptünk el sem indul. Mindenféle ellenőrzés nélkül kerülnek a szerverre a form adatok.
- A klienstől a szerver felé küldés közben (a JavaScript ellenőrzés után) a küldött adatok manipulálhatók. Mire a szerverre érnek, az adatok megváltoztathatóak (szándékos hack kísérlet)
HTML Form felépítése
Amennyiben a HTML dokumentumunkba űrlapot kívánunk elhelyezni, azt a form elem segítségével kell megtennünk. Ehhez a HTML elemhez (tag) mindíg kell lezáró elemet is írni. Egyetlen HTML dokumentumba több form-t is elhelyezhetünk. Ez esetben mindegyikhez saját visszaküldési gombot (submit button) kell elhelyezni, és aktiválásakor csak az adott submit gombhoz tartozó form adatait küldi vissza. Ez igen zavaró lehet, mivel a felhasználó minden form összes mezőjét kitöltheti, de ezek nagy részét ekkor feleslegesen.
A form mezők esetén minden beviteli elemnek nevet (name) kell adni. A felküldéskor név-érték párosok kerülnek felküldésre (mintha változó értékadásokat látnánk, pl "nev=lajoska"). Ezért egyrészt minden form elemnek kötelező nevet adni, másrészt ezen neveknek az adott formon belül egyedieknek kell lenni!
A form elem nevét a programozók választják. Nem szokás ékezetes betűket használni, és kifejezetten nem szokás szóközt alkalmazni a form elem nevében. Hagyományosan csak angol ABC betűit (elsősorban kisbetűket), számjegyet, aláhúzást alkalmazunk.
A form elem értéke a felhasználó által kerül kitöltésre. Ebben természetesen már vad dolgok is előfordulnak (ékezetes betűk, szóköz, különleges karakterek, mint az aposztróf, százalékjel, stb). A HTML szerint ezen nem szokványos karaktereket kódolva kell átküldeni a klienstől a webszerverre, hogy az esetleg jelen lévő kódlap különbségek ne okozzanak zavart. Gondoljunk csak bele, amint egy kínai ügyfél a 'mi a neved' kérdésre a kínai billentyűzettel szerelet laptopján komolyan veszi a kérdést, és beírja. Vizualizáljuk az angol nyelvű linux szerveren futú CGI program zavarát, amint megpróbálja értelmezni! A kódolást (és a webszerven dekódolását) az urlencode és urldecode módszerek tárgyalják.
Az űrlap egyik legfontosabb eleme az action, amely megadja, hogy az űrlap adatait hova kell visszaküldeni. Ez jellemzően ugyanazon webszerver egy CGI/FastCGI alkalmazására, vagy scriptjére mutat. Nem gyakori, de lehetséges, hogy a visszaküldés nem ugyanazon web szerverre mutat, mint ahonnan a form maga letöltődött.
<form
action=”http://somesite.com/prog/adduser/index.php”
method="post”
enctype=”...”
accept-charset=”...”
accept=”...”
name=”...” >
....
</form>A másik fontos eleme a method, mely a visszaküldési módszert definiálja. A HTTP protokoll ugyanis kétféle módszert támogat, a get és post módot.
A get mód nem kifejezetten a form mezők visszaküldésére lett kitalálva, de alkalmazható erre is. A post a gyakoribb módszer. Ez az alapértelmezett módszer is, tehát ha a form fejrészében ezt nem adjuk meg külön, akkor automatikusan a post módszer lesz alkalmazva.
POST metódus
Vizsgáljuk meg mi történik meg, ha a formok esetén általában használt post metódust választjuk:
<form action=”...” method="post”>
...
</form>Ez esetben a submit (felküldés) gomb hatására a form elemek bekerülnek a HTTP kérés szövegébe (lásd lenti példa):
POST http://somesite.com/prog/adduser/index.php HTTP/1.1
PHPSESSID=mlbvlvgs7aqb6ldu4vrfj3ldo2
Content-Type: application/x-www-form-urlencoded
Content-Length: 233
fej_sid=11&sid=32&fej_canmodify=false&row_id=0&biz_szam=c111&biz_tipusa=1&datum=2009.12.22&
cel=&partner=Alpinkabel&hatarido=2009.01.12&fokszam=0711&osszeg=32212
HTTP/1.x 200 OK
A Content-Length (tartalom hossza) írja le, hogy 233 byteot használunk el az adatok küldésére. Az adatok ez alatt helyezkednek el. Mindíg név-érték párosokból áll, melyek között a határoló jel az et-jel (& karakter). A Content-Type-ben is jelezve van, hogy amennyiben az értékek speciális karaktereket tartalmaznának, úgy az url-encode módszer van alkalmazva annak kódolására. A szerver ezt olvasván automatikusan futtatja az url-decode módot az adatok feldolgozása előtt.
A látványos része a post beküldésnek, hogy a form adatai a felhasználó elől láthatatlan módon kerül elküldésre. A submit gombra kattintva a fenti adatküldés megtörténik, a böngészőjében a kiírt link az action-ban szereplő lesz, esetünkben a http://somesite.com/prog/adduser/index.php kerül kijelzésre. Amennyiben az oldalt újratölti (F5 billentyű, vagy menüből), a legtöbb böngésző megkérdezi, hogy valóban újra akarja-e küldeni a form adatokat a szerverre. Ez veszélyes lehet, hiszen ha a formban egy banki utalást írtunk le, melyben pénzt utaltunk el valahova, újraküldés esetén a szerver értelmezheti azt még egy utalási utasításnak is!
GET metódus
A GET módszer esetén a form adatok beküldése nem ilyen láthatatlan, hanem nagyon is látható módon történik meg. A formhoz rendelt action url egészül ki, ide kerülnek a form adatok. Itt biztosan az url-encode módszert alkalmazza a böngésző a küldéskor, hiszen a generált url meg kell feleljen a szigorú előírásoknak (nem tartalmazhat pl. szóközt).
<form action=”...” method=”get”> ... </form>
Ez esetben a küldés (submit) után a böngészőben az alábbi link lesz látható:
http://somesite.com/prog/adduser/index.php?fej_sid=11&sid=32&fej_canmodify=false &row_id=0&biz_szam=c111&biz_tipusa=1&datum=2009.12.22&cel=&partner=Alpinkabel& hatarido=2009.01.12&fokszam=0711&osszeg=32212
POST versus GET
- A két megoldás egyenértékű funkcionalitást biztosít
- POST metódussal a link "szép" marad
- GET metódussal a link kézzel szerkeszthető a user által (biztonsági rés)
- mindkét esetben manipulálhatóak az adatok küldés előtt (jobb ha tudjuk, bár POST esetén kissé nehezebben)
- A szerver oldalon tudni kell, hogy post vagy get módszerrel lettek küldve az adatok, hiszen az adatok kiolvasása nem ugyanazon módszerrel történik (pl. PhP esetén egyik esetben a $_GET, másik esetben a $_POST tömbbe kerülnek az adatok).
