Sessions of cookies
Cookie lijkt me wel handig aangezien dit ook op subdomeinen werkt en dat je zelf kiest hoe lang je ingelogd blijft.
Wat wel een nadeel is dat je cookies gewoon kunt aanpassen en kijken welke value dat heeft, of ik moet het beveiligen met een algoritme, maar als dat algoritme uitlekt is dan weer heel het systeem lek...
Wat zouden jullie doen?
Een cookie geeft aan welke sessie bij welke gebruiker hoort, niet wat er in die sessies staan. de inhoud van sessies zijn dus, in tegenstelling tot cookies, voor de eindgebruiker niet zichtbaar.
@ts gebruik sessies, kijk eens hier als je het ook over subdomeinen wil gebruiker.
voor het gebruiken van de session op subdomains kan je eventueel kijken naar session cookies / session.cookie_domain..
of gebruik maken van een eigen session wrapper...
Gewijzigd op 26/04/2012 21:41:58 door Marco PHPJunky
Officieel dan.
Jens erd op 26/04/2012 21:33:41:
Precies, daarom lijkt het mij ook duidelijk welke van de twee je het beste kunt gebruiken.@simon
Een cookie geeft aan welke sessie bij welke gebruiker hoort, niet wat er in die sessies staan. de inhoud van sessies zijn dus, in tegenstelling tot cookies, voor de eindgebruiker niet zichtbaar.
Een cookie geeft aan welke sessie bij welke gebruiker hoort, niet wat er in die sessies staan. de inhoud van sessies zijn dus, in tegenstelling tot cookies, voor de eindgebruiker niet zichtbaar.
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
$userId = session_name("naam");
session_set_cookie_params(0, '/', '.site.nl');
session_start() or die('Kon geen sessie starten.');
?>
$userId = session_name("naam");
session_set_cookie_params(0, '/', '.site.nl');
session_start() or die('Kon geen sessie starten.');
?>
Gewijzigd op 26/04/2012 22:54:29 door - Raoul -
Nu heb ik reeds zo'n 13 sessies aan te maken met websitedetails per gebruiker betreft configuratie ervan.
Of raden jullie mij aan om steeds bij ELKE pagina dat wordt ingeladen steeds de info uit de database te halen ?(en dus vele malen een DB-connectie te openen )
Verder wordt in zo'n beetje elke dynamische website een DB connectie gemaakt per pagina, dus zo vreemd is het niet. Het is zelfs goed om en iets in de DB en iets in een sessie te stoppen.
Raoul, die 'or die' hoort daar natuurlijk niet thuis...
Kijk maar eens naar de linkerkant van deze website, naar
"Actief op PHPhulp", "Laatste forum berichten", ...
Dit wordt nergens gecache't. Elke keer je ergens op klikt, wordt dat opnieuw berekend, op basis van gegevens die in een db staan.
Wat dit betreft, lijkt het me interessant om al die informatie in de DB bij te houden.
Als je hier van uit gaat...
Je kan een unieke code zetten in een veld in de db. Uniek, dus bruikbaar als id.
Als je dat random laat genereren, kan een hacker ook niet zomaar de zelfde id +1 uitproberen.
Wat blijft er dan nog over van de vraag?
zowel cookie als session hebben enkel die ene code nodig om alle settings te lezen.
Het lijkt me dat je dan simpelweg kiest voor
cookie => de gegevens moeten bewaard blijven, als de gebruiker de webbrowser sluit en opnieuw opent.
sessie => de gegevens blijven bewaard zolang de gebruiker de webbrowser open laat.
Gewijzigd op 27/04/2012 14:34:13 door Kris Peeters
Michel DS op 27/04/2012 07:27:53:
Nu heb ik reeds zo'n 13 sessies aan te maken met websitedetails per gebruiker betreft configuratie ervan.
13 sessies of 13 sessie variabelen?
Waarom heb je in vredesnaam 13 verschillende gegevens nodig van een gebruiker over de gehele site? Ik kan me iets voorstellen als je naar zijn persoonlijke instellingen of iets dergelijks gaat maar anders kan ik er weinig nut in zien eerlijk gezegt.
Ik probeer het meestal tot een maximum van 5 variabelen te houden, puur voor het feit dat je straks bij god niet meer weet welke variabelen nu ook al weer wat inhouden als je met zulke aantallen werkt.
Ik vind dat nog steeds de key voor programmeren simpel en netjes is, houdt het zo simpel mogelijk waar dit kan. Bijvoorbeeld als je een ww wilt beveiligen, ga dan niet eerst $pw = $_POST['pw'}; $md5pw = md5 ($pw) doen maar pak het samen in 1 zoals $md5pw = md5 ($_POST['pw']);.
Klinkt logisch maar je wilt niet weten hoeveel mensen dit niet doen en een 'simpele' code zo veel regels en declaraties in beslag laten nemen dat je er de slappe lach van krijgt. Tevens neemt al die declaraties ook veelste veel resources van je sever in beslag.
En gebruik maken van een DB voor zoveel specifieke gegevens lijkt me wel slim idd, nogmaals ik kan me geen situatie indenken waar je 13 verschillende gebruikers gegevens op elke pagina van je website nodig hebt.
Enerzijds zou ik zeggen dat het slim is, zodat je de naam niet op iedere pagina uit de database hoeft te halen, maar van de andere kant... mocht iemand een sessie-bestand hacken, dan weet men wie de persoon is die daarbij hoort.
Dus wat is handiger: de naam opslaan in de sessie en daarmee database aanroepen besparen, of de naam telkens uit de database halen?