setcookie("userid",$userid,$tijd_lengte,"/");
setcookie("securhash",$hash,$tijd_lengte,"/");
// of is het beter zo
setcookie("securcookie",$userid.";".$hash,$tijd_lengte'"/");
Het komt hier dus opneer:
OF twee cookies met ieder apparte informatie OF 1 met beide informatie erin. Dan zou ik gewoon voor 1 cookie gaan... waarom die gegevens appart in losse cookies opslaan?
Ik vind dat je eigenlijk zelf moet kiezen, maar ik zou zeggen dat het wel extra moeite vraagt om nog een stukje code te schrijven om de cookie te splitsen. Je mag van dat gebruiken op voorwaarde dat je zeker bent dat dat splits tekens (in dit geval de ';') niet zomaar voorkomen in de strings.
Wat het verschil is... een nutteloze handeling. Als het echt om twee verschillende gegevens zou gaan kan ik het nog wel begrijpen.
Juist door het te combineren kan je meer verwarring creeren omdat je dan niet zo 1 2 3 kunt achterhalen welke gegevens waarvoor staan.
Maar ook dat vind ik een beetje nutteloos. Je moet er juist voor zorgen dat je geen gevoelige informatie in een cookie opslaat. Maar de gegevens in een cookie in combinatie met gegevens in de database zouden voor de veiligheid moeten zorgen
ja dat gaat ook dienen als beveiliging, een userID en een security hash van (minstens 50 tekens) gaat in een cookie komen te staan en dan controleer ik in de DB als het userID en de unike hash overeen komen
maar ik denk dat ik dan 2 cookies ga gebruiken, maar de naam die ik via setcookie geef, is dat ook de naam van het txt of krijgt die txt een andere naam ?
@advg: alleen met sessie werken gaat ook, maar dan kan een gebruiker niet ingelogt blijven omdat ls je de browser sluit de sessie verloopt
En in het cookie sla je de userID en een unieke hash op. Wanneer je de website laat controleren op het cookie haal je hieruit de userID en unieke hash op. Tevens controleer je het IP-adres van de pc waar het cookie op staat. Deze gegeevns controleer je met de tabel stored_cookies en als er een match is dan is het goed.
Nee, je slaat alleen de userID en hash-code op in een cookie.
De overige gegevens sla je op in een database...
@avdg:
Nee dat zou ik niet doen... alleen een sessieID opslaan in een cookie is niet zo veilig. Zorg dan ook nog voor een ip-controle door deze gegevens op te slaan in een database
geen IP adres in cookie opslaan! Je slaat dat WEL op in de database. Waarom? Voor extra veilgheid. Stel iemand 'jat' een cookie van een pc en plaatst deze op een andere pc en doet er nog meer stoute dingen mee. Dit cookie zal nooit geaccepteerd worden omdat in de database er geen cookie gegevens staan voor dat IP adres icm userID en hashcode.
En in het cookie sla je de userID en een unieke hash op. Wanneer je de website laat controleren op het cookie haal je hieruit de userID en unieke hash op. Tevens controleer je het IP-adres van de pc waar het cookie op staat. Deze gegeevns controleer je met de tabel stored_cookies en als er een match is dan is het goed.
Zoiets. Maar waarom zou je op userID gaan controleren als de hash toch uniek is? Hij controleert tenslotte op de hash en het ip, dus userID zou alleen maar overbodig zijn. Je kant het makkelijk met de volgende sql doen:
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
