Első webfejlesztős munkahelyemen (még a múlt évezredben) tanultam meg, hogy a cookie-kkal mértékkel kell bánni, mivel nem korlátlan adattárolási eszközről van szó. Ezzel a legtöbb webfejlesztő valószínűleg tisztában is van, azzal viszont talán nem, hogy mennyi ez a limit, és hogy hogyan lehet megkerülni.
Mindenekelőtt fogadjuk el, hogy ma már modern böngésző nincsen meg cookie kezelés nélkül, és hogy megengedhető kompromisszum a cookie-k használata különböző webes alkalmazások esetén. Persze van, aki kikapcsolja a cookie támogatást, de ha valami komplex webalkalmazást készítünk, mindenképpen szükségünk lesz a cookie kezelésre, ha máshoz nem, hát a beléptetéshez, a session kezeléshez.
Mennyi a limit?
A különböző limiteket, a limitek átlépésének megoldásait viszonylag részletesen szedte össze az NCZOnline egy browser cookie restrictions című bejegyzésében. A közös nevező 30 süti per domain, és sütinként névvel, egyenlőségjellel és értékkel együtt 4095 karakter (vagy byte?). A sütik számát az Opera, egy süti nagyságát pedig az Internet Explorer határolja be, bár itt az Opera 1, a Firefox és a Safari pedig 2 karakterrel előzi meg. Ez azt jelenti, hogy akár 120kB-ot is le tudunk tárolni sütik segítségével, de amikor ezt számolgatjuk, figyeljünk arra, hogy az oldalba még lehet, hogy különböző mérőkódokat, statisztika scripteket is rakhatunk, melyek különböző információk letárolásához cookie-kat használnak!
A limit egyébként abból az időszakból jön, amikor még nem lehetett kapni 1 TB-os winchestert, de azt is lássuk be, hogy ma sem szeretnénk, ha minden weboldal 1 GB-nyi adatot letárolna minden korlátozás nélkül, csak úgy. A kliens oldalon tárolható adatmennyiség limitálása tehát mindenképpen egy hasznos és szükséges megoldás – ezért érdekes, hogy a fenti bejegyzés szerint a Safari segítségével akár 10.000 sütit is beállíthatunk.
Hogy kerüljük meg?
A legegyszerűbb és legbarátságosabb megkerülési forma, ha a cookie csak egy azonosítót tárol, a többit pedig szerver oldalon tároljuk, ehhez a cookie-hoz kapcsolva, de ez csak akkor jó megoldás, ha a kliens oldalon nincsen szükség a teljes adathalmazra. Ha webalkalmazásról van szó, akkor ilyenkor le lehet húzni a letárolt adatokat az oldal betöltődésekor, vagy pedig dinamikusan azt, amire éppen szükség van. Sajnos a JavaScript teljesítménnyel viszonylag kisebb mennyiségű adat dolgozható fel kliens oldalon, néhány művelet elvégzése szerver oldalon gazdaságosabb lehet. Nyilván az alkalmazástól függ, hogy jó-e ez a megoldás.
Ha akár offline is működő alkalmazásokról beszélünk, és tényleg szükségünk van kliens oldali adattárolásra, akkor a Dojo alkalmazáskönyvtár Dojo Storage modulja környékén érdemes nézelődnünk, mely az adott böngészőben éppen rendelkezésre álló megoldáshoz alkalmazkodva többféleképpen is meg tudja oldani az adattárolást. Két megközelítés működik, a Flash alapú, és a böngészőkbe épített, szabványos, de a még nem igazán elterjedt WHAT WG ajánlásra épülő megoldás.
A Flash Local Storage a Flash 6-os változata óta elérhető megoldást használ, így 100kB-ot is le tudunk tárolni a felhasználó engedélye nélkül (kényelmesebben, mint ha a cookie-kkal való bűvészkedéssel tennénk), de ha elérjük ezt a határt, akkor sem kell megállnunk, mert ha a felhasználó engedélyezi, további erőforrásokat érhetünk el (inkrementálisan, 1MB-onként kell engedélyt adni).
A WHAT WG által képbe hozott DOM Storage API a Firefox 2.0-tól elérhető, meglepő módon nem túl ismert lehetőség. Érdemes a Firefox oldalán levő dokumentációt elolvasni ezügyben, ott a konkrét megvalósításról kaphatunk információkat. A doksikban nem szerepel, és túl sok információt nem találtam a dologról, de kb. 5MB-nyi információ tárolható le ezen a módon John Resig szerint.
Úgy emlékszem, hogy volt egy időszak, amikor a Dojo Storage is támogatta, de ma már valamiért nem, a Google Gears megoldását. A Gears böngésző kiterjesztésnek az egyik szolgáltatása egy a SQLite interfész, mely segítségével emlékeim szerint korlátlanul használhatjuk a böngésző által elérhető tárolókapacitást, miután a felhasználó engedélyt adott az adott webalkalmazásnak a hozzáférésre. Gears sajnos nincsen (még?) Firefox 3-ra, amúgy Firefox 2, Internet Explorer böngészőkben, Mac OS X, Linux és Windows XP/Vista (plusz Windows Mobile 5 és 6) alatt is elérhető.
Egyebek
Ha nem webalkalmazást írunk, hanem asztali környezetben futó HTML+CSS+JS alkalmazást, akkor több lehetőségünk van, az egyik a “sima” fájl alapú tárolás, Firefox motor esetén pedig akár SQLite alapokon is dolgozhatunk.
Összefoglalás
Ha tényleg szükségünk van valamilyen kliens oldali adattárolásra (gondoljuk végig!), akkor a fenti megoldások közül lehet érdemes választani. A Flash elég sok böngészőn elérhető, a Firefox szépen terjed, a Gears pedig talán kijön Firefox 3-ra is (vagy csavarnak egyet a dolgon valahogy a szabványos megoldások irányába).
Jó kis összefoglaló, és csak annyit fűznék hozzá, hogy a sütikkel adatmennyiség terén érdemes vigyázni, mert ugye minden request-el együtt elmennek a szerver felé. Tehát egy 100kB-os sütit állandóan feltöltögetni nem túl barátságos.
Plusz tegnap találtam rá, hogy a ff3-ban vannak offline/online események (http://developer.mozilla.org/en/docs/Online_and_offline_events). Bár ez nem igazán a témához kapcsolódik, csak a Gearsről jutott eszembe
Ezt is ki szerettem volna már próbálni, csak még nem volt rá lehetőségem: http://taffydb.com/
Webkit-ben, de talán már safari 3-ban(?) is van lehetőség kliens oldali sqlite adatbázis használatára…
Csak kötözködés tényleg, de SQLite, nem SQLLite…
rgranc: éreztem hogy valami nem stimmel, kösz, javítva!
most jott ki egy tarolasi modszert elfedo kis js lib: http://pablotron.org/?cid=1557
inSay: valóban, és az is egész jónak tűnik.
Zila: valóban a 3.1-esemben benne van ez a szolgáltatás (http://webkit.org/misc/DatabaseExample.html), lehet hogy már előbb is volt ilyen (régi fejlesztés: http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/)
duplabe: jó hogy mondod ezt a cookie elküldést, erre baromira nem gondoltam. még egy érv az alternatív megoldások melett.
Az offline működésen gondolkodtam:
Ha van egy webalkalmazás, sütiben tárolunk adatokat és közben elmegy a net …. dolgozunk tovább, további adatokat rakunk a sütibe, aztán kikapcsoljuk a gépünket. Másnap ha bekapcsoljuk, felkonnektálunk, visszakapjuk a sütiket, amik akkor lettek rögzítve, amikor nem volt netkapcsolat?
Úgy gondolom, hogy működnie kéne, csak olyan hihetetlennek tűnik, hogy ne lenne itt valami bug, vagy működésbeli eltérés a böngészők közt.
Zrek: A cookie tárolás azért elég megbízhatóan működik minden böngészőben.
De nem feltétlenül a sütik a jó megoldás erre a célra, inkább a fenti valamelyik könyvtárral a Flash vagy hasonló lehetőség kihasználása (JavaScriptből).
Először is, köszi a bejegyzést, érdekes volt. A hozzászólásoknál meg úgy is említettétek, hogy a sütik nem csak a böngészőt, hanem a szervert is terhelik.
A bejegyzést olvasva készítettem egy jQuery plugin-t, Fx és IE alatt működik, de biztos lehet találni ennél kifinomultabb megoldásokat is.
Balogh Tibor: Szuper, köszi! Hihetetlen, hogy ez a lehetőség már az Internet Explorerben 5-ben (1999. március) is benne volt, és csak most kezd(het) el elterjedni. Tisztára mint az XMLHttpRequest esetében. Aki hozzám hasonlóan egy WTF-ot dobott a fenti kódban a behaviouros megoldás láttán: http://msdn.microsoft.com/en-us/library/ms531424.aspx
Nincs mit! – A kódból hiányzik az s deklarációja.
Igen, én is tőled találtam meg a leírást:
(Bártházi András) => (John Resig) => MDC => MSDN => Az általad megadott oldal, keresgélés után.
Arról lehet tudni vmit hogy ez mennyire biztonságos? Mennyire tudja maga a felhasználó a tárolt adatot módosítani, ill. mondjuk távolról egy másik honlap, link…
Egy újabb megoldás: PersistJS (http://pablotron.org/?cid=1557)
Péter: olvass utána az egyes oldalakon – másik honlap nem fér hozzá, amúgy meg annyira biztonságos mint bármilyen más információ, amit a saját gépén tárol a felhasználó.
duplabe: szuper, lehet hogy összehozok egy másik bejegyzést is ezekből.
duplabe-jegyzés: a név kötelez!