---

Jeg har en site hvor jeg gerne vil gemme information undervejs i en
brugers besøg. Hidtil har jeg brugt sessions, men svjks kan man ikke
bestemme hvor lang sessionen varer. Den ser ud til pr definition at være
indtil browseren lukkes.

Derimod kan man jo med setcookie angive en udløbs tid. Betyder det at
jeg skal gå fuldstændig væk fra at bruge $_SESSION og anvende $_COOKIE i
stedet? Eller kan man linke de to?

Sagt på en anden måde: er session og cookies konceptuelt et enten-eller
eller er de tænkt til at supplere hinanden?

--
peace, love & harmony
Atte

http://www.atte.dk

---

On Fri, 09 Dec 2005 11:57:51 +0100, Atte André Jensen wrote:

> Sagt på en anden måde: er session og cookies konceptuelt et enten-eller
> eller er de tænkt til at supplere hinanden?
Sessions og cookies kan sagtens leve i sameksistens. Der bliver blot
skrevet en ekstra HTTP header i stil med følgende:
Set-Cookie: PHPSESSID=123456788990...
Set-Cokkie: someName=someValue

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

"Michael Rasmussen" <mir@miras.org> skrev i en meddelelse
news:pan.2005.12.09.23.52.56.393609@miras.org...
> Sessions og cookies kan sagtens leve i sameksistens. Der bliver blot
> skrevet en ekstra HTTP header i stil med følgende:
> Set-Cookie: PHPSESSID=123456788990...
> Set-Cokkie: someName=someValue

Derved skal man så også være opmærksom på, at der bliver brugt en smule
ekstra båndbredde på at overføre dem. Med sessions bliver der (vidst nok)
kun overført et slags id.

Også at huske at man ALDRIG må gemme adgangskoder og lignende i cookies, da
cookies også kan sniffes via. netværket computeren er forbundet til. Igen
vil det ikke fungere på samme måde med sessions (som jeg nok mener har
beskyttelse mod at man sniffer id'et og bruger det).

Du kan selvfølgelig omgå alt det her, ved at lave din egen form for
"sessions". Lav et slags "id" udfra brugerens browser, ip-adresse, os osv.,
og gem evt. al data i en database (MySQL evt.?). Derved får du selv kontrol
over udløbstiden m.m., som man altid mangler med sessions.

Bare lige et par reminders ;)


--
Med venlig hilsen
Kasper Johansen

---

Kasper Johansen wrote:

> Også at huske at man ALDRIG må gemme adgangskoder og lignende i cookies, da
> cookies også kan sniffes via. netværket computeren er forbundet til. Igen
> vil det ikke fungere på samme måde med sessions (som jeg nok mener har
> beskyttelse mod at man sniffer id'et og bruger det).


Hvis der benyttes HTTP ved login, så kan passwordet sniffes her.

Som default er session id ikke beskyttet. Så et sniffet id, kan fint
benyttes af andre. Selv bag en anden ip.

---

jamen wrote:
> Kasper Johansen wrote:
>
>> Også at huske at man ALDRIG må gemme adgangskoder og lignende i
>> cookies, da cookies også kan sniffes via. netværket computeren er
>> forbundet til. Igen vil det ikke fungere på samme måde med sessions
>> (som jeg nok mener har beskyttelse mod at man sniffer id'et og bruger
>> det).
>
> Hvis der benyttes HTTP ved login, så kan passwordet sniffes her.

Jeps. Man kan komme omkring det problem med et
challenge-response-system, hvor serveren sender en challenge
(<challenge>), tid (<tid>) og klienten sender hash(concat(<challenge>,
<tid>, <password>)). For at gøre det, må man bruge javascript.

Er der iøvrigt nogen der ved hvor udbredte de indbyggede, HTTP-baserede
challenge-response-mekanismer efterhånden er?

> Som default er session id ikke beskyttet. Så et sniffet id, kan fint
> benyttes af andre. Selv bag en anden ip.

Det forudsætter at man bruger det meget kort tid efter at man har samlet
det op, da de lagrede sessionsdata ellers bliver slettet efter ikke at
have været i brug i noget tid.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf