ugrás a tartalomhoz

Custom session handler és setcookie (Set-Cookie header kétszer jelenik meg)

janoszen · 2005. Aug. 18. (Cs), 14.45
Sziasztok!

Úgy tünik, ma sok kérdésem van. :) Helyzet a következö:

Írtam egy custom session handler-osztályt. Namost, mivel elég komplex rendszert írok, ezért szeretném, ha a be- és kimenet külön osztály vezérelné (IOhandler).

Sajnos a custom session handler ellenére is automatikusan kiküldi a cookie-kérést a session_start(). Ezt mutatja az, hogy két külön Set-Cookie-header van, ha megnézem a kimenetet a böngészön.

Kérdésem: rá lehet venni a PHP-t arra, hogy ne küldjön ki magától cookie kérést?

Köszi

ProClub
 
1

session save handler

Poetro · 2005. Aug. 18. (Cs), 15.37
custom session handler alatt a session_set_save_handler beállítását érted? Mert ha igen, akkor az csak a session eltárolásának módját változtatja meg. A PHP ugye alapértelmezetten egy fájlba menti le a session változókat, amik valami ideiglenes könvtárba kerülenek, és a PHP a beépített készítés, törlés stb beépített függvényeit használja. Ezt tudod felüldefiniálni, de a PHP-nak valahogy tudni kell, hogy mi is az aktuális sessionazonosító, ezért ezt a php.ini-ben beállított módon kezeli. (GET paraméterben vagy Cookie-ban menjen a session azonosító továbbítása) Azaz ezeket a php.ini-ben tudod beállítani, és jól is működnek. session változók cookie-ban történő tárolása nem egészséges és felettébb nem biztonságos.
--------
Poetro
2

RTFM: session.use_cookies

Hojtsy Gábor · 2005. Aug. 18. (Cs), 19.02
Na, erre tényleg van kész megoldás (szerintem :) session.use_cookies
3

Köszönöm. :)

janoszen · 2005. Aug. 19. (P), 09.55
Ha! Köszönöm! Tényleg lehetett volna több RTFM, de kossz kulcsszó alatt kerestem. :D

Egyébként a Session cookie-knál mi lenne biztonságosabb?

ProClub
4

Session Cookie

Poetro · 2005. Aug. 19. (P), 12.57
Az addig rendben van, hogy a Session azonosítót cookie-ban tárolod, viszont minden bejelentkezéskor új sid-et érdemes generálni. A session változókat viszont mindig a szerverren szabad csak tárolni, ráadásul úgy, hogy más felhasználók ne férhessenek hozzá.
Ui: létezik szerkesztés link is ám, nem kell újra beküldeni a javított változatot (mármint ha csak helyesírási hibát javítasz).
--------
Poetro
5

:)

janoszen · 2005. Aug. 19. (P), 13.58
Nos, a szerkesztés linket használtam, mégis újra bepakolta. :) Sorry, ez van.

Session-röl: eszem ágában sincs bármiféle adatot a felhasználónál tárolni. :) A bejelentkezésenként új SID jó ötlet, köszi, szerintem, alkalmazni fogom, de igazából nem tárolok olyan iszonyatosan hétlakatos titkokat. :)

ProClub
6

új session id

Balogh Tibor · 2005. Aug. 20. (Szo), 21.32
"igazából nem tárolok olyan iszonyatosan hétlakatos titkokat"
Akkor teljesen felesleges minden oldallekéréskor új munkamenet-azonosítót generálni. Csak lassabban fog letöltődni az oldalad.

"A szerkesztés linket használtam, mégis újra bepakolta."
Én úgy vettem észre, hogy csak azokat a hozzászólásokat szerkeszthetem, amikre még nem válaszoltak.

"Egyébként a Session cookie-knál mi lenne biztonságosabb?"
https és védett süti
8

oldallekérés != bejelentkezés

Hodicska Gergely · 2005. Aug. 21. (V), 12.19
Szia!

Akkor teljesen felesleges minden oldallekéréskor új munkamenet-azonosítót generálni. Csak lassabban fog letöltődni az oldalad.
Bejelentkezésről volt szó, ott pedig igancsak javallott: lényegesen csökkenti a session hijacking esélyét (lásd ajánlott cikk).

Minden kéréskor váltogatni a sessionidt amúgy sem túl bölcs dolog, hiszen ha a támadó mégis megszerzi a sessionid-t, akkor egy oldallekéréssel teljesen kizárja a megtámadott felhasználót. Ilyesmi funkciót úgy érdemes csinálni, hogy generálsz kérésenként egy változó azonosítót, amit lementesz sessionbe, és belerakod az oldalba is, és a válaszban ellenőrzöd az azonosító meglétét.


A védett süti mit fed? Így még nem hallottam.


Felhő
7

A forrás ;-)

Hodicska Gergely · 2005. Aug. 21. (V), 12.09
Szia!

Egyébként a Session cookie-knál mi lenne biztonságosabb?

Munkamenet kezelés biztonsági kérdései


Felhő