ugrás a tartalomhoz

Saját SESSION kezelés

smart · 2011. Szep. 7. (Sze), 16.33
Sziasztok, egy olyan triviális kérdéssel fordulnék hozzátok, hogy mi haszna származik abból az embernek, ha nem a beépített SESSION-t használja, hanem sajátot ír?

A kérdés alapötletét a "SESSION eltünedezik." fórumtéma adta.

Az ott feltüntetett kódot megnézve bennem több kétely is felmerült. A módszer előnyét viszont egyáltalán nem látom. Gyorsabb? Biztonságosabb? Ad valami extra funkciót? Miért jó ilyet csinálni? :)
‹ PHP - MYSQL Asszonynevek ›
 ■
1

Ha adatbázisba írod az

Hidvégi Gábor · 2011. Szep. 7. (Sze), 16.43
Ha adatbázisba írod az adatokat, akkor az gyorsabb és biztonságosabb lehet (a motor optimalizáltsága miatt), mint a fájlműveletek. Emellett a terheléselosztásban is segíthet, mert a munkamenet adatait több szerverről is elérheted. Ennél gyorsabbak már csak a különböző memcached megoldások lehetnek.

"Ad valami extra funkciót?" - ha leprogramozod, akkor igen : )

Úgy tudom, hogy a sebesség miatt komolyabb weboldalakon saját munkamenet-kezelőt használ mindenki.
3

gyorsabb és biztonságosabb

Poetro · 2011. Szep. 7. (Sze), 16.51
gyorsabb és biztonságosabb lehet (a motor optimalizáltsága miatt)

Miért is lenne gyorsabb? Az operációs rendszer is optimalizálja a fájlrendszer hozzáféréseket, a gyakori fájlokat memóriában tartja stb. Sőt megfelelő fájlrendszer mellett sokkal biztonságosabb is lehet, mint az adatbázis.
4

Az Adatbázisrendszerek

Hidvégi Gábor · 2011. Szep. 7. (Sze), 17.29
Az Adatbázisrendszerek megvalósítása című könyvben olvastam, hogy komolyabb adatbázismotorok a táblák sorainak fizikai helyét a merevlemez forgási adatainak figyelembevételével (sebesség, távolság a lemez szélétől stb.) határozzák meg, ami jelentősen felgyorsíthatja fix hosszúságú sorok olvasását és írását. Emellett ugyanúgy van írási és olvasási gyorstáruk, ezért úgy gondolom, hogy sebességben jobb lehet, mint amilyet az operációs rendszer tud nyújtani.

Egy tranzakciós adatbázis pedig a biztonságot növeli, bár szerintem ezen a szinten egyenértékűek a raid-ekkel.
5

Ezeket a paramétereket

H.Z. v2 · 2011. Szep. 7. (Sze), 18.34
Ezeket a paramétereket sokszor már az op.rendszer sem ismeri, mert csak x méretű virtuális diszket kap pl. SAN-on.
Lokális diszkekkel lehet, hogy meg tudnák oldani az adatbázisok, de ami elég komoly ahhoz, hogy ilyesmire vetemedjen, azok alatt többnyire olyan tároló alrendszerek vannak, amik ezeket a dolgokat elfedik az adatbáziskezelő és az op.rendszer elől.
(mondom ezt úgy, hogy én szinte kizárólag ilyet láttam, de csak egyetlen munkahelyem volt ;-) )
6

Ebben valószínűleg igazad

Hidvégi Gábor · 2011. Szep. 7. (Sze), 19.27
Ebben valószínűleg igazad van, nekem csak ez a könyv a forrásom, közvetlen tapasztalatom nincs a témában.
11

Ezt most

H.Z. v2 · 2011. Szep. 10. (Szo), 08.36
Ezt most találtam:
http://www.dcs.vein.hu/CIR/cikkek/Database_Theory.pdf

A 13. oldal régi, szép emlékeket ébresztett bennem. :-)
Cilinder, fizikailag több trackkel, szektorok stb.
Anno R22-n, ICL-en dolgoztam ilyen 5,10 és 20MB-os(!! :D) diszkekkel. Ott még volt létjogosultsága a fizikai tároláshoz kapcsolódó optimalizálásnak. Az csak ennek kapcsán jutott eszembe, hogy már a néhány évvel később megjelent IDE vinyóknál sem lehetett ismerni az adatok valódi fizikai elhelyezkedését, mert sok esetben "hazudtak" a gemoetriát illetően a meghajtók.
12

Úgy tűnik, mégiscsak

Hidvégi Gábor · 2011. Okt. 11. (K), 15.05
Úgy tűnik, mégiscsak számítanak a fizikai paraméterek, legalábbis MySQL-ben:
One of the features found in the summer 2011 labs release is the ability to select the InnoDB page size without recompiling. Smaller page sizes may be useful for certain storage media such as SSDs where there is no need to minimize seek time between reads.
2

Időtartam

Poetro · 2011. Szep. 7. (Sze), 16.47
Például az, hogy hozzáférsz más emberek session-jéhez, saját magad tudod szabályozni a lejártukat, akkor is tudsz bele adatot írni, tudsz bennük keresni, amikor nem épp az illető felhasználó kérését teljesíted. Például meg tudod mondani, hogy egy adott pillanatban hány felhasználó van az oldalon (vagy legalábbis hány felhasználónak él a session-je). Hogy gyorsabb-e ez csak attól függ, mit használsz a session adatok tárolására. Ha például valamilyen memória alapú tárolót (Memcache, Redis), akkor gyorsabb, ha adatbázis alapút, akkor jelentősen lassabb is, ugyanakkor tudod a kettőt kombinálni. Azaz az alkalmazás a session adatokat cachelheti memóriába, és ha nincs meg az adat memóriában, csak akkor fordul az adatbázishoz. Így a session azután is újra tud éledni, hogy például a szervert, vagy a memória alapú tároló szolgáltatását újraindítod.
7

Érdemes saját sessiont

MadBence · 2011. Szep. 7. (Sze), 23.28
Érdemes saját sessiont használni, a beépített (enyhén szólva) nem tökéletes. Pl régen az ilyen ingyen tárhelyeken (extra.hu), a session amit te írtál, simán megjelent az összes többi oldalon (pl ha volt X oldalon a sessionban egy isAdmin változó, azt te egy Y oldalon (amit te írhatsz) simán átírhattad true-ra, visszamentél meglátogatni az oldalt, és máris megemelt jogosultsággal találtad szemben magad)
8

Hiba

Poetro · 2011. Szep. 7. (Sze), 23.42
Az az ottani beállítások hibája. Na meg persze nem tudom, hogyan működött az extra.hu, de biztosan be lehet ezt állítani biztonságosra.
9

Re: Érdemes saját sessiont

smart · 2011. Szep. 8. (Cs), 07.47
Bevallom, azért ennél jobb példára gondoltam. :) Ha a rendszer úgy van beállítva, hogy a session-okat felül tudják írni a különböző juzerek, akkor vajon mennyi az esély arra, hogy a fájlok, vagy az adattáblák biztonságba vannak, és ahhoz senki sem fér hozzá?
De, ha mégis, akkor is egy egyszerű session_name('sajat_azonositom'); utasítással ezt ki tudom kerülni. Ezért nem kell felülírni az alapértelmezett session kezelést.
10

re: session_name ()

razielanarki · 2011. Szep. 8. (Cs), 11.32
a session_name() csak a session cookie nevét írja át, ha jól emlékszem :)

én pl egy saját session kezelőbe írtam egy olyan funkciót h ún browser fingerprint-et is tárol a session_id mellé, ezzel is megnehezítve, azaz csökkentve a session lopás kockázatát.