A InfoWiki wikiből
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).
