ugrás a tartalomhoz

session id adatbázisban

inf · 2013. Aug. 6. (K), 18.45
Szerintetek van e értelme adatbázisban tárolni a munkamenetet?

Az a gondom, hogy a jelszót, meg minden mást azért hash-eli az ember, hogy sql injectionnel ne lehessen lopni. Ha a session id bekerül az adatbázisba, akkor simán lopható a munkamenet sql injectionnel, nem kell erőfeszítést tenni a visszefejtésre, vagy bármi ilyesmire...
‹ logikai kapu $_SERVER['HTTP_REFERER'] átriányítás után ›
 ■
1

Kulcs

Poetro · 2013. Aug. 6. (K), 18.55
Azt megteheted, hogy a kliens rendelkezik egy kulccsal (sütiben tárolva), ami segítségével ki lehet nyitni a session_id-t, azaz nem a ténylegeset tárolod, hanem egy kódoltat.
2

Szerintem ne tároljunk semmit

MadBence · 2013. Aug. 6. (K), 19.00
Szerintem ne tároljunk semmit adatbázisban, mert simán lopható sql injectionnel :). A munkamenetet mindenképpen adatbázisban érdemes tárolni (kivéve, ha neked hosszútávon megfelelnek az in-memory/filesystem/stb, nem igazán skálázódó megoldások).
3

Ez most egy 100 felhasználós

inf · 2013. Aug. 6. (K), 21.27
Ez most egy 100 felhasználós kis oldal lesz, úgyhogy megfelel a normál php-s fájlrendszeres megoldás, egyébként memóriába tenném (ha nagyobb szabású projekt lenne). Annyi extra van, hogy egyedül a jogosultság, ami szerver oldalon marad, minden mást áttettem kliensbe, szóval adatot nem is nagyon kell tárolni... Így már nagyjából minden kerek. Átgondolom kicsit jobban, aztán megvalósítom.

A másik megoldás, hogy csinálok két db felhasználót, az egyik hozzáfér a session-höz, és az azzal kapcsolatos adatokhoz, a másik meg minden máshoz. Ha így a munkamenetes rész teljesen le van védve sql injection-re, akkor a másik sql felhasználónál hiába injektálnak, nem tudják elkérni a session tábla tartalmát.

Egyelőre most egyszerűbb a fájlrendszeres megoldás...
4

Nem igazán értelek:

H.Z. · 2013. Aug. 6. (K), 22.01
Nem igazán értelek: PDO/mysqli+prepared statement = SQL injection kicsukva.
Egyébként ha van lehetőséged több adatbázis user létrehozására, akkor célszerűnek tűnik minden jogosultsági szinthez más usert használni.

Jogosultsági szint alatt értem, hogy
- lekérdező
- update
- admin
5

Persze, hogy PDO prepared

inf · 2013. Aug. 6. (K), 22.03
Persze, hogy PDO prepared statementet tolok, de az ördög nem alszik... Nem feltétlen magamra gondoltam, hanem ha későbbiekben valaki felhasználja a kódomat...
6

Úgy jár

Poetro · 2013. Aug. 6. (K), 23.01
Akkor majd úgy jár, mint a földnélküli paraszt: magára vet.
7

Hát a nyílt forrású

inf · 2013. Aug. 7. (Sze), 02.15
Hát a nyílt forrású szoftvereknél nem hiszem, hogy az lenne az alapelv, hogy szopassuk meg a másikat...
8

Ez mintha épp arról szólna:

H.Z. · 2013. Aug. 7. (Sze), 07.13
Ez mintha épp arról szólna: http://hup.hu/node/126054 ;)
9

A fájlalapú munkamenetkezelés

Hidvégi Gábor · 2013. Aug. 7. (Sze), 08.17
A fájlalapú munkamenetkezelés előnye, hogy a kérés idejére a fájlt zárolja a rendszer, így más nem férhet hozzá, azaz biztos lehetsz abban, hogy ha két kérést egymás után indítasz, mindig időrendben érkezik válasz. Ha nincs zárolás, akkor ez nem garantált, elképzelhető, hogy ha mondjuk az első kérés lassan fut le, a második gyorsan, és hamarabb is tér vissza, akkor nem lesznek konzisztensek a visszakapott adatok (ha van összefüggés a két kérés között).
10

Kevésbé marketinges

tgr · 2013. Aug. 7. (Sze), 09.17
Kevésbé marketinges megközelítésben a fájlalapú munkamenetkezelés hátránya az, hogy a kérés idejére a fájlt zárolja a rendszer, azaz nem tudsz párhuzamosan több kérést kiszolgálni, és kicsit is komoly terhelésnél fejreáll a szerver.
12

Miért áll fejre? Csak az

Hidvégi Gábor · 2013. Aug. 7. (Sze), 10.08
Miért áll fejre? Csak az adott felhasználó nem tud párhuzamosan több kérést indítani, az pedig az alkalmazástól függ, hogy ez előny vagy hátrány. Internetes szolgáltatásnál, ahol már komolyabb késleltetések vannak, nem is biztos, hogy célszerű párhuzamos kéréseket indítani, hanem jobb egyben elintézni mindent. Másrészt nem feltétlenül kell minden kéréshez elindítani a munkamenetkezelőt.
20

Tud párhuzamosan több kérést

tgr · 2013. Aug. 10. (Szo), 20.55
Tud párhuzamosan több kérést indítani, csak azok nem fognak visszatérni, csak ha már a leglassabb is befejeződött. Vagyis többszörösére nő az adott pillanatban párhuzamosan futó PHP threadek száma (vagy ha konstans méretű thread poolt használsz, töredékére csökken a párhuzamosan kiszolgálható felhasználók száma).
13

ez a fájl zárolás dolog per

szabo.b.gabor · 2013. Aug. 7. (Sze), 10.09
ez a fájl zárolás dolog per session történik, tehát felhasználónként..
14

Jobb adatbázisokban van

inf · 2013. Aug. 7. (Sze), 12.15
Jobb adatbázisokban van olyan, hogy select for write...
16

for update - legalábbis ha

H.Z. · 2013. Aug. 7. (Sze), 12.17
for update - legalábbis ha szabvány SQL-ről beszélünk.
Azt hiszem...
11

Az in-memory megoldások

tgr · 2013. Aug. 7. (Sze), 09.22
Az in-memory megoldások (memcache stb) speciel sokkal jobban skálázódnak, mint az adatbázis, ezért nagy terhelésű rendszereknél ilyenekben is szokták tartani a session adatokat.
15

Tudok róla, hozzáértő

inf · 2013. Aug. 7. (Sze), 12.16
Tudok róla, hozzáértő ismerősöm már ajánlotta, hogy inkább memóriában kellene, mert az a tuti... (Mondjuk itt pont az ellenkezőjét írták - amit persze nem hiszek el - de mivel nem értek hozzá, nem tudom megcáfolni.)
17

Félreértés

MadBence · 2013. Aug. 7. (Sze), 13.27
In-memory tároláson én leginkább az alkalmazáson belüli in-memory tárolást értettem (tehát pl berakjuk egy tömbbe, ami ott vegetál a folyamat memóriaterében), nem a Redis/memcached megoldásokat.
18

Csak ugye PHP-ban ezt máshogy

Joó Ádám · 2013. Aug. 7. (Sze), 14.38
Csak ugye PHP-ban ezt máshogy nem tudod megcsinálni, mint egy ilyen alkalmazással kommunikálva…
19

APC vagy shm_* is tud

tgr · 2013. Aug. 10. (Szo), 20.47
APC vagy shm_* is tud memóriában tárolni. Az APC nem is feltétlenül rossz megoldás, ha csak egy szervered van és nagyon rövid session timeout (a fájlbetöltésnél sokkal gyorsabb); skálázni persze nem lehet.