[php]Waarom zou je cookies ipv sessions gebruiken

[simon]

Het verbaast mij dat er een heleboel scripts zijn die 'nog' niet op sessions zijn overgestapt. Waarom zou je cookies gebruiken? Ik zelf vind sessions veel makkelijker en veiliger.

[Rotjeknor]

Dit zijn twee totaal verschillende dingen. Ik ga de precieze verschillen niet uitleggen, daar weet ik (nog) te weinig over.

Wat voor mij juist voor de overgang van sessies naar cookies zorgde, was het feit dat je met cookies een tijd kan instellen hoelang die nog geldig blijft. Zo kan je dus zorgen dat je 'onbeperkt' ingelogd bent.

[Verwijderd]

dit heeft ook te maken met een persoonlijke voorkeur denk ik.
bij sessions kun je ook gebruik maken van cookies (andersom geld dan natuurlijk ook )
ligt eraan wat je precies wil bereiken etc.

[CyeZ]

Rotjeknor schreef op 10 september 2002 @ 17:14:
Dit zijn twee totaal verschillende dingen. Ik ga de precieze verschillen niet uitleggen, daar weet ik (nog) te weinig over.

Wat voor mij juist voor de overgang van sessies naar cookies zorgde, was het feit dat je met cookies een tijd kan instellen hoelang die nog geldig blijft. Zo kan je dus zorgen dat je 'onbeperkt' ingelogd bent.

Met dit:

session.cookie_lifetime specifies the lifetime of the cookie in seconds which is sent to the browser. The value 0 means "until the browser is closed." Defaults to 0.

Is dat ook aardig te omzeilen. Enige probleem zijn dan nog mensen die totaal geen cookies kunnnen/willen ontvangen. Maar die heb je met de cookie-only aanpak ook niet.

[Soultaker]

Waarom zou je gegevens zelf opslaan, als de bezoeker dat voor je wil doen? Als je niet gehecht bent aan de betrouwbaarheid van je gegevens en het aantal gegevens beperkt is, kun je ze prima in een cookie kwijt.

Voor uitgebreide data en het beschermen van gevoelige informatie zijn sessions natuurlijk beter geschikt. Ook kun je gegevens die in een cookie hadden gekund, ook wel in een session kwijt, dus wat dat betreft kun je sessions inderdaad wel overal voor gebruiken.

Een laatste voordeel van cookies is dat ze 'portable' zijn tussen verschillende servers en applicaties; een door PHP ingestelde cookie kan door een CGI applicatie in Perl of C gelezen worden. Dat is met (PHP) sessies niet (zomaar) het geval.

[saryon2413]

<preek>
Met cookies kan je bijna hetzelfde als wat je met sessies kan, en met sessies kan je bijna hetzelfde als je met cookies kan.
namelijk:
gegevens bewaren over meerdere paginas op een site.

Cookies wil je meestal bewaren als je gegevens op de gebruiker z'n computer op wil slaan. Dit kan bijvoorbeeld zijn omdat je wil dat de gebruiker z'n gegevens niet kwijt raakt als ie z'n computer/browser uit zet. Door dan cookies te gebruiken, die op de machine van de gebruiker blijven (MITS goed gedaan), kan je de gegevens dan daar vandaan halen, of via een database of watooit.
Sessies wil je gebruiken als je veilige data nodig hebt, en dus geen cookies wil gebruiken, juist omdat die op de computer van de gebruiker te vinden is. Dat gegeven zorgt er nl. voor dat de gebruiker deze cookies kan muteren (ook weer af te vangen, maja), en dus foute/corrupte data kan versturen. Sessies worden op de server opgeslagen, en kunnen dus niet veranderd worden door de gebruiker (MITS je $_SESSION[variabele] gebruikt in je code, ipv de global $variabele). Een nadeel van sessies daarentegen is dat de gegevens niet bewaard blijven nadat je de browser afsluit.

Sessies en cookies zijn even handig, het hangt er gewoon af van wat je er mee wil doen.

</preek>

Ik zelf gebruik bijna uitsluitend sessies, en een database om de gegevens die ik over een periode bewaard wil hebben op te slaan, en dan met cookies terug te halen. Dat is (denk ik) een van de meest veilige manieren om met cookies te werken: data is nog steeds op de server opgeslagen, en die md5 die ik in de cookie zet zorgt er wel voor dat als de gebruiker iets bogus stuurt, dat ie z'n gegevens gewoon kwijt raakt.

[supakeen]

Sessions worden toch opgeslagen in de /tmp waar iedereen kan lezen en schrijven

[saryon2413]

dat klopt....bijna
-heb jij toegang tot een webserver (anders dan je eigen?)
-heb je de rechten al bekeken? 400 voor de webserver, dus zelfs als je toegang hebt, kan je er niets mee, tenzij je # bent (of je windows draait)

[simon]

Ok, dat begreep ik dus ook, maar er zij nog aardig wat scripts waar gevoelige informatie wordt opgeslagen in een cookie, op een manier die niet 'veilig' is.
Is het ontwetendheid van programmeurs of is het iets anders?

[Verwijderd]

zmn schreef op 10 september 2002 @ 18:22:
Sessions worden toch opgeslagen in de /tmp waar iedereen kan lezen en schrijven

Standaard wel ja, maar je kan ook sessie handlers schrijven zodat je ze bijvoorbeeld in een database op kan slaan

http://www.php.net/manual...sion-set-save-handler.php

[Verwijderd]

Als jouw site als enige op een webserver draait kan je makkelijk sessions gebruiken, maar als je een webserver moet delen met nog tig andere users zou ik het bij cookies houden. Dus als je zelf geen invloed hebt op de instellingen van php (php.ini) en niet weet wanneer die /tmp leeggegooid kan worden gebruik dan cookies.
Sessions hebben natuurlijk enkele voordelen t.o.v. cookies, zo kan je makkelijker met arrays werken in session en is de capaciteit groter. Een cookies is gelimiteerd tot afaik een item of 28.

[Bender]

waarom zou je sessions ipv cookies gebruiken?
Als de mensen hun eigen cookie met hun username etc verkloten is dat hun eigen schuld..
veredr zorg ik zowiezo dat veilige informatie steeds opgevraagd word, en niet afhangt van de user

[Zoolander]

Hoe denken we hier nu, een jaar later over?
Het enige voordeel op cookies, zoals ik dat zie, is dat de info langer bewaart blijft.
Voor de rest: sessions rule.

TOCH?

[Johnny]

Ik gebruik ze altijd door elkaar.

Als een gebruiker aangeeft automatisch te willen inloggen wordt er een cookie met daarin een id en een hash van wat info opgeslagen.

Als de bezoeker de website bezoekt en er is nog geen sessie gestart dan wordt er gekeken of er een cookie is, aan de hand daarvan worden de gegevens uit de database gehaald en in de sessie gezet.

[Suepahfly]

Ik heb destijds voor cookies gekozen om dat ik *snel* een inlog modules moest maken. Op dat moment had ik nog nooit met sessions gewerkt.

[MeIsTwisted]

ik vind sessies veel makkelijker werken, veiliger en werkt bij iedereen.

hoogstens idd voor de langere levensduur zou ik cookies gebruken. Anders sessies

[whoami]

Sessions en cookies zijn imho complementair.

Je kan sessies niet vervangen door cookies, en andersom.
Trouwens, is het niet zo dat je in de meeste systemen eigenlijk enkel sessies kunt gebruiken als de client cookies enabled heeft?
(In ASP.NET kan je dat omzeilen door gebruik te maken van cookie-less sessions).

[creative8500]

Ik zag laatst inderdaad dat PHP zelf een cookie aanmaakte voor PHPSESSID

[Genoil]

whoami schreef op 21 november 2003 @ 13:43:
Sessions en cookies zijn imho complementair.

Je kan sessies niet vervangen door cookies, en andersom.
Trouwens, is het niet zo dat je in de meeste systemen eigenlijk enkel sessies kunt gebruiken als de client cookies enabled heeft?
(In ASP.NET kan je dat omzeilen door gebruik te maken van cookie-less sessions).

Ja dat is zo. Bij gebruik van sessies wordt het sessie-id ook gewoon in een koekje gestopt. Ook PHP kent truucjes om het sessie-id ook zonder koekje door te geven, door dynamisch achter elke URL in de output een extra GET var met het sessie-id erin mee te geven.

[whoami]

Ik vraag me eigenlijk af waarom jullie sessies met cookies vergelijken.

IMHO gebruik je een cookie om een waarde/waardes op te slaan en opgeslagen te houden ook als de gebruiker zijn sessie beëindigd, zodat, als hij jouw site opnieuw bezoekt bepaalde voorkeuren opnieuw kan ophalen, of zodat hij ingelogged kan blijven.
Sessie-variabelen gebruik je imo enkel voor variabelen die je nodig hebt gedurende de sessie.

[stekkel]

whoami schreef op 21 november 2003 @ 13:43:
Sessions en cookies zijn imho complementair.

Je kan sessies niet vervangen door cookies, en andersom.
Trouwens, is het niet zo dat je in de meeste systemen eigenlijk enkel sessies kunt gebruiken als de client cookies enabled heeft?
(In ASP.NET kan je dat omzeilen door gebruik te maken van cookie-less sessions).

In php omzeil je dat door gebruik te maken van session.use_trans_sid.

De SID wordt dan automatisch met de url meegegeven.

edit:

Dat was dubbelop, genoil merkte het al op .

[ Voor 6% gewijzigd door stekkel op 21-11-2003 15:33 ]

[Zoolander]

Hmm leuke reacties!
Maar ehm, met SESSIONS worden er volgens mij GEEN cookies aangemaakt op de CLIENTside, maar op de SERVERside. Dus dat is niet ECHT een koekje. (leuk woord )

Ik gebruik altijd SESSIONS omdat ze hetzelfde kunnen als cookies, alleen ze gaan dood wanneer je de browser sluit.

[LauPro]

Ik gebruik een cookie om een sessie-id op te slaan. Meestal werken gebruikers achter meerdere pc's en zijn cookies daarom niet handig om informatie op te slaan (zoals Startpagina e.d. doen voor de 'persoonlijke startpagina'). Wat je in een cookie wel kwijt kan is dus de informatie om toegang te hebben tot een sessie. Dan kunnen mensen op verschillende systemen met dezelfde sessie werken.

[MikeN]

Zoolander schreef op 21 november 2003 @ 22:13:
Hmm leuke reacties!
Maar ehm, met SESSIONS worden er volgens mij GEEN cookies aangemaakt op de CLIENTside, maar op de SERVERside. Dus dat is niet ECHT een koekje. (leuk woord )

Voor een sessie wordt wel degelijk een cookie op de client aangemaakt, tenzij jij het sessionid via de url doorgeeft (standaard wordt dat bijna niet gebruikt).

Ik gebruik altijd SESSIONS omdat ze hetzelfde kunnen als cookies, alleen ze gaan dood wanneer je de browser sluit.

Het zijn verschillende dingen.

Cookies gebruik je om "even" iets op te slaan voor een levensduur van 0 tot oneindig.
Sessies moet je IMHO alleen _per sessie_ gebruiken en gebruiken om data op te slaan. Zo kan bijvoorbeeld een winkelmandje van een webshop heel mooi in een sessie. Terwijl een forum voor de logins het beste gebruik kan maken van cookies, je wilt tenslotte graag ingelogd blijven, ook als je je browser sluit. Verder hoeft er weinig info opgeslagen te worden tussen pagina's onderling, het kan steeds weer makkelijk uit de DB worden opgevraagd.

Verder twijfel ik nogal aan de veiligheid van sessies. Tenzij je met een eigen save handler gaat werken worden de files lokaal op de disk van je server opgeslagen, iets wat op een shared host niet echt veilig is.

[ Voor 7% gewijzigd door MikeN op 21-11-2003 22:23 ]

[Verwijderd]

als ik zo de topic titel lees kan ik alleen antwoorden: weet je wel waar je het over hebt.

sessies: deze gebruik je om specifieke data te behouden als een persoon de site bezoekt. Dit kan bijv. een laatste zoek opdracht zijn, een user id, groep id, auth nivo etc etc

cookies: deze gebruik je om de persoon weer te herkennen zodra deze opnieuw op de site komt of om bepaalde instellingen te bewaren. Bijv. inlog gegevens.

Je bent knap debiel bezig als je bijv. een userid of een group id in een cookie opslaat en deze iedere keer checkt als je een handeling doet. Je hebt namelijk geen controle over een cookie (iedere user kan hem veranderen e.d.) terwijl je wel controle over een sessie heb, alleen JOUW script kan hem wijzigen.

Ik weet van sommige 'scripters' dat zij doodleuk een admin level of user id in een cookie opslaan en zodra er iets gewijzigt e.d. moet worden wordt in de cookie gekeken naar admin level of user id.

tja.. dan kan je net zo goed zo'n javascript login etc gebruiken, dat is volgens mij dan nog veiliger

[Zoolander]

Aha! "als ik zo de topic titel lees kan ik alleen antwoorden: weet je wel waar je het over hebt."
Leuke zin, hehe. Maakt niet uit. Je hebt ergens wel een punt.

Ja, zoiets dacht ik al wel.
Alleen dat er iets op de clientside werd opgelsagen wist ik weer niet, althans dit kan toch nooit meer zijn sessionID die Md5 versleuteld is? Ja dat is zo.
Dus om het echt veilig te maken ook nog SSL gebruiken dus! Security is een lastig topic, maar wel het volgende waar ik naar toe ga!

Dank!

[MisterData]

Ik gebruik nu sessies als de gebruiker is ingelogd en een cookie om een 'sessie-record-id' in m'n database op te slaan, zodat die gebruiker bij terugkomst gelijk weer is ingelogd

[whoami]

Zoolander schreef op 21 november 2003 @ 22:13:

Maar ehm, met SESSIONS worden er volgens mij GEEN cookies aangemaakt op de CLIENTside, maar op de SERVERside. Dus dat is niet ECHT een koekje. (leuk woord )

Het cookie wordt clientside gemaakt, want dat cookie wordt gebruikt omdat de server zou weten welke sessie de client heeft.
Cookies op de server bewaren zou nogal nutteloos zijn.

Ik gebruik altijd SESSIONS omdat ze hetzelfde kunnen als cookies, alleen ze gaan dood wanneer je de browser sluit.

Een sessie gaat niet dood als de browser afgesloten wordt, maar als de sessie beëindigd wordt.
Het kan zijn dat je je browser afsluit, maar dat de sessie eigenlijk nog een aantal minuten blijft leven op de server.
De server weet immers niet dat jij je browser hebt afgesloten.

[bartvb]

BTW een user automatisch in laten loggen via alleen een cookies is nogal lastig, hiervoor zijn sessies IMO veel beter geschikt. Of ja, via een cookie is het makkelijk te doen, maar meestal zijn die oplossingen of totaal niet veilig of weinig charmant

Ander punt (voor mij iig) is dat de cookie info bij _iedere_ hit opgestuurd wordt door je user. Dus ook als ze 30 gifjes/pngtjes ophalen van 200 bytes per stuk. Als ze voor die ieniemienie plaatjes telkens een mega HTTP header opsturen tikt dat op den duur nogal aan als je redelijk wat waarden in je cookie hebt gegooid. Met sessies hoeft de user alleen het session ID mee te sturen, dat is alles dat in het cookie staat.

Enige voordeel van het gebruik van cookies is voor mij dat het met cookies gemakelijker is om simpele dingetjes (layout setting b.v.) voor lange tijd op te slaan. Kan met sessions ook maar dan moeten je sessions een flinke tijd geldig blijven wat nogal overkill is als je alleen wilt weten in welke kleur deze user de site wil zien.

Maar goed, cookies gebruiken voor autologin is meestal nogal brrr.

[hobbit_be]

bartvb schreef op 22 november 2003 @ 11:35:
BTW een user automatisch in laten loggen via alleen een cookies is nogal lastig, hiervoor zijn sessies IMO veel beter geschikt. Of ja, via een cookie is het makkelijk te doen, maar meestal zijn die oplossingen of totaal niet veilig of weinig charmant

Mag jij mij eens uitleggen hoe je met sessions (ie niet eens een 'fixed' principe) na een reboot zou weten wie de user is?

Cookie: bijhouden van de identity van een client across time om ZONDER meerdere logins (en als gevolg nieuwe 'sessies' of states te moeten werken) te werken. Cookies zijn unsafe en mag je dus niet gebruiken voor sensitive info. Maar het is vaak wel convenient om op zijn minst de user erin op te slagen...

Sessions: Hoe van stateless HTTP een statefull oplossing te maken. Dit kan op verschillende manieren, incluis het gebruik van cookies. (Dit word trouwens aangeraden in de PHP manual, aangezien anders iemand je sessie kan hijacken).

(ASPX heeft zo zijn methode om alle info van een page naar een volgende over te dragen in het html document zelf).

Nou goed. Als het veilgi moet zijn gebruik je HTTPS en niets anders (of je moet met Java applets / ActiveX gaan werken).

Zelf gebruik ik cookies dus ook gewoon als HINT voor de server en het session mechanisme doet er niet toe. Als je geen server hebt met dynamic support moet je JavaScript + Cookies doen.

[simon]

Zoolander schreef op 21 november 2003 @ 23:54:
Aha! "als ik zo de topic titel lees kan ik alleen antwoorden: weet je wel waar je het over hebt."
Leuke zin, hehe. Maakt niet uit. Je hebt ergens wel een punt.

Het was al een tijd terug toen ik dit topic opende, onderhand is mij wel heel wat meer duidelijk geworden op dat gebied.

Maar wat ik mij nu het meest afvraag, ik zie veel scripts gecode worden, en ik zie veel coders die enorm onveilige situaties creëren, door onveilige situaties te creëren met het opslaan van gegevens (username, userid) in de cookie. Ze doen dat op zo'n manier dat het stikt van de lekken. Met sessions is dat veel makkelijker uittesluiten, en ik zie de moeilijkheid er niet van in, dat was het punt dus

[RedRose]

Aansluitend op hobbit_be: de session handling van PHP heeft niets met veiligheid van doen. Sessions zijn een manier om data per gebruikerssessie serverside op te slaan. Cookies een manier om clientside 'state' te bewaren. Sterker nog: PHP-sessions gebruiken of een client-side cookie of een session-id in je $_GET om state te bewaren. Sessions met cookies vergelijken, vind ik dan ook appels en peren vergelijken. Het zijn twee verschillende dingen, met elk een ander doel.

Hoe dan ook: veiligheid van je scripts hangt er niet vanaf of je sessies of cookies gebruikt, maar hoe je jouw eigen sessiesysteem implementeert, met alles wat daar bij komt kijken.