Személyes eszközök
Keresés

 

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).


A lap eredeti címe: „http://wiki.ektf.hu/wiki/Cgi-ea/page002
Nézetek
nincs sb_35.172.224.102 cikk