Database Sessie Handler
Door CB2thephp , 21 jaar geleden, 5.135x bekeken
Ik zag in de wishlist het volgende staan:
- Een eigen sessie handler (database/file based backend) (zowel script als tutorial)
Toen ik dit zag dacht ik hé ik gebruik er een. Dus ik dacht laat ik het maar eens toevoegen. Het script zorgt voor een veiliger session save path, namelijk de database. Waarom is het veiliger, omdat bij publieke servers de session path meestal wordt gedeeld. Hierdoor krijgen andere mensen gewoon de kans je sessie te grijpen, niet goed dus.
Hiervoor zorgt het volgende script een block voor, maar een nadeel je wachtwoord van database etc.
Dit kun je echt ook blokkeren, door namelijk in de apache config wat laten toevoegen. Je moet namelijk het volgende moeten toevoegen. Hierdoor komt het in de SERVER array :), alleen wees dan voorzichtig met je phpinfo() :D
SetEnv DB_USER "user"
SetEnv DB_PASS "pass"
Vraag hiervoor je hosts als je het zelf niet kan, ze kunnen het makkelijk toevoegen in je virtualhost bestand en anders probeer htaccess en zorg ervoor dat alleen apache dan mag lezen. Hoe je dat moet doen zoek maar uit :P
Het is goed getest, geen enkele fout ben ik zeker van.
Voorbeeld: http://Geen
Gesponsorde koppelingen
PHP script bestanden
Er zijn 18 reacties op 'Database sessie handler'
0 
-0 
-0
Dit is gewoon een overwrite van een session starter, het heeft niks met gebruikers te maken, gewoon doen hoe je normaal ook met sessions werk ;)
Dat is de mooie eraan :D, dus geen enkele script zal raar gaan werken!
Dat is de mooie eraan :D, dus geen enkele script zal raar gaan werken!
0 -0
-0
Waarom $_SERVER als opslagruimte gebruiken voor een gebruikersnaam en wachtwoord?
0 -0
-0
Dit is een veel veiliger methode, omdat in een php bestand zetten etc nog een risco is, want hackers op een zelfde server kunnen het namelijk uitlezen, als ze slim zijn ( Heb ik wel een code voor als voorbeeld :D, zelfs met .php als uiteinde ). De SERVER array daarin tegen kan alleen door de server zelf worden opgevraagd, dus een heel stuk veiliger, want het kan niet worden uitgelezen zoals ze dat via de php bestand kunnen doen. Daarvoor moeten ze jou virtualhost gedeelte hebben en dat kunnen ze echt niet krijgen :D.
0 -0
-0
Ik snap je niet helemaal, maar als je toegang hebt tot PHP, kun je toch ook gewoon een bestandjemaken?
0 -0
-0
Dat kan gelukkig niet, wegens apache, want hoe de persoon het ook probeert hij maakt de script via zijn virtualhost gebied, dus kan hij alleen zijn eigen SERVER variabelen lezen, en niet van een andere omdat het een andere virtualhost gebied is en dus een andere SERVER array :), sorry voor de onduidelijkheid.
0 -0
-0
TIP:
Maak van data een BLOB of MEDIUMBLOB veld zodat het binary safe is. Of geef op zijn minst dan het textveld een binaire collatie. Maak een constante aan met SESSION_COMPRESSION_LEVEL die de data van de sessie compressed met bijvoorbeeld gzip compress :)
Nog meer tips bij het beter bekijken:
Waarom?
1. Door typecasting wordt het altijd geconverteerd naar een nummer (integer) dus voorkomt meteen het injection probleem.
2. Als je in MySQL een integer waarde gebruikt, mag je in de niet-strict modus deze in quotes zetten waardoor MySQL de string converteerd naar een integer,good practice is als je integers gebruikt (ook in MySQL) deze niet in quotes te zetten omdat MySQL ze anders toch weer moet omzetten, en theoretisch scheelt dit tijd..
Misschien heb ik nog meer tips zo :p
Nog eentje dan:
Maak van het veld "access" een andere naam sowieso iets zoals insertdate, is veel directer en meer zeggend, wat mij betreft. En maak er een veld van met het MySQL timestamp datatype, met on_update_current_timestamp en als default waarde current_timestamp ;)
Vervolgens doe je bij het verwijderen van sessies:
Op mijn werk scheelde dit gewoon halve seconden tot seconden query tijd, dit voornamelijk omdat MySQL nu de berekening intern in zijn tabel zelf kan doen, wat veel sneller is.
Maak van data een BLOB of MEDIUMBLOB veld zodat het binary safe is. Of geef op zijn minst dan het textveld een binaire collatie. Maak een constante aan met SESSION_COMPRESSION_LEVEL die de data van de sessie compressed met bijvoorbeeld gzip compress :)
Nog meer tips bij het beter bekijken:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$SQL = "SELECT id,access,data FROM sessions WHERE id='{$id}'";
//zou ik als volgt doen:
$SQL = 'SELECT id,access,data FROM sessions WHERE id='.(int)$id;
?>
$SQL = "SELECT id,access,data FROM sessions WHERE id='{$id}'";
//zou ik als volgt doen:
$SQL = 'SELECT id,access,data FROM sessions WHERE id='.(int)$id;
?>
Waarom?
1. Door typecasting wordt het altijd geconverteerd naar een nummer (integer) dus voorkomt meteen het injection probleem.
2. Als je in MySQL een integer waarde gebruikt, mag je in de niet-strict modus deze in quotes zetten waardoor MySQL de string converteerd naar een integer,good practice is als je integers gebruikt (ook in MySQL) deze niet in quotes te zetten omdat MySQL ze anders toch weer moet omzetten, en theoretisch scheelt dit tijd..
Misschien heb ik nog meer tips zo :p
Nog eentje dan:
Maak van het veld "access" een andere naam sowieso iets zoals insertdate, is veel directer en meer zeggend, wat mij betreft. En maak er een veld van met het MySQL timestamp datatype, met on_update_current_timestamp en als default waarde current_timestamp ;)
Vervolgens doe je bij het verwijderen van sessies:
Code (php)
1
2
3
2
3
<?php
$sql = 'DELETE FROM sessions WHERE insertdate > (NOW() - INTERVAL 15 MINUTE)';
?>
$sql = 'DELETE FROM sessions WHERE insertdate > (NOW() - INTERVAL 15 MINUTE)';
?>
Op mijn werk scheelde dit gewoon halve seconden tot seconden query tijd, dit voornamelijk omdat MySQL nu de berekening intern in zijn tabel zelf kan doen, wat veel sneller is.
0 -0
-0
Het eerste heb ik gedaan.
Heel goeie tip voor het geval iemand binary code gebruikt, maar dit zie je niet vaak bij een session.
De tweede heb ik niet gedaan, waarom?
Nooit iets zippen wat nooit veel data zou bevatten, want de meeste sessionwaardes hebben gewoon een kleine waarde tot 40 tekens en niet meer en dit maakt een compression het niet waard.
De derde heb ik niet gedaan, waarom?
Dit is totaal niet mogelijk, want de id die php genereerd voor een session bestaat niet alleen uit een integer het bestaat ook uit a's en b's etc. Dus een id van een session altijd op een varchar houden. Je kunt het trouwens ook geen ints van forceren, want dit blijkt php niet te accepteren.
De vierde heb ik niet gedaan, waarom?
Niemand gaat hier last van hebben met zijn eigen scripts, want eigenlijk mag niemand met een andere script in deze tabel, het is alleen voor de php session handler bedoelt. Dus alleen dit script mag aan dit deel van je database komen elk andere niet doen. DUS AFBLIJVEN LAAT PHP DE SESSION MET DIT SCRIPT REGELEN EN NIET JIJ! Moest even caps gebruiken xD, als forcering.
De vijfde ga ik doen.
Hierin heb je gelijk, maar voordat ik het doe moet ik eerst kijken wat het verschil tussen die van mysql en php is dan kan ik pas een aanpassing maken.
Heel goeie tip voor het geval iemand binary code gebruikt, maar dit zie je niet vaak bij een session.
De tweede heb ik niet gedaan, waarom?
Nooit iets zippen wat nooit veel data zou bevatten, want de meeste sessionwaardes hebben gewoon een kleine waarde tot 40 tekens en niet meer en dit maakt een compression het niet waard.
De derde heb ik niet gedaan, waarom?
Dit is totaal niet mogelijk, want de id die php genereerd voor een session bestaat niet alleen uit een integer het bestaat ook uit a's en b's etc. Dus een id van een session altijd op een varchar houden. Je kunt het trouwens ook geen ints van forceren, want dit blijkt php niet te accepteren.
De vierde heb ik niet gedaan, waarom?
Niemand gaat hier last van hebben met zijn eigen scripts, want eigenlijk mag niemand met een andere script in deze tabel, het is alleen voor de php session handler bedoelt. Dus alleen dit script mag aan dit deel van je database komen elk andere niet doen. DUS AFBLIJVEN LAAT PHP DE SESSION MET DIT SCRIPT REGELEN EN NIET JIJ! Moest even caps gebruiken xD, als forcering.
De vijfde ga ik doen.
Hierin heb je gelijk, maar voordat ik het doe moet ik eerst kijken wat het verschil tussen die van mysql en php is dan kan ik pas een aanpassing maken.
0 -0
-0
"Dus alleen dit script mag aan dit deel van je database komen elk andere niet doen."
Met GRANT dus de juiste rechten op deze tabel instellen, dan loop je hier geen risico's mee.
Met GRANT dus de juiste rechten op deze tabel instellen, dan loop je hier geen risico's mee.
0 -0
-0
@CB2thephp:
1. Een binair data type is beter vanwege de ruimte die hij in beslag neemt voor de karakters. Je zou ook een tekst veld kunnen gebruiken met de goede collatie, maar vind ik het een princiepe kwestie om BLOB te pakken. Sowieso omdat je sessie data geen gegevens zijn, voor de database dan.
2. Op mijn werk werd er veel in de sessie weg geschreven waardoor dit op kan lopen tot 40KB per record. Als je heel wat ingelogde gebruikers hebt kan dit best oplopen waardoor de tabel traag wordt. Gzippen was hier voor ons de oplossing. Het was dus maar een tip waarbij je zelf moet kijken of het past in jouw omgeving.
3. Mijn fout, ik had niet direct door dat het om een ID ging met diverse karakters. Waarom gebruik je niet gewoon nummers als session identifier ? Ik doe dit zelf ook, vanwege performance en integriteit. En wat accepteerd PHP niet ?
4. Je moet het uiteraard zelf weten, maar het woord "access" zegt mij niet direct dat het gaat om een tijd specificatie die zegt wanneer een sessie acties is geworden, de bedoeling van PHPHulp is volgens mij dat je kennis/code/etc deelt met elkaar?
5. Het verschil is dat MySQL het sowieso sneller is en als je er een timestamp veld van maakt kun je date functies gebruiken op dit veld, omdat MySQL weet dat het om een datum gaat..
1. Een binair data type is beter vanwege de ruimte die hij in beslag neemt voor de karakters. Je zou ook een tekst veld kunnen gebruiken met de goede collatie, maar vind ik het een princiepe kwestie om BLOB te pakken. Sowieso omdat je sessie data geen gegevens zijn, voor de database dan.
2. Op mijn werk werd er veel in de sessie weg geschreven waardoor dit op kan lopen tot 40KB per record. Als je heel wat ingelogde gebruikers hebt kan dit best oplopen waardoor de tabel traag wordt. Gzippen was hier voor ons de oplossing. Het was dus maar een tip waarbij je zelf moet kijken of het past in jouw omgeving.
3. Mijn fout, ik had niet direct door dat het om een ID ging met diverse karakters. Waarom gebruik je niet gewoon nummers als session identifier ? Ik doe dit zelf ook, vanwege performance en integriteit. En wat accepteerd PHP niet ?
4. Je moet het uiteraard zelf weten, maar het woord "access" zegt mij niet direct dat het gaat om een tijd specificatie die zegt wanneer een sessie acties is geworden, de bedoeling van PHPHulp is volgens mij dat je kennis/code/etc deelt met elkaar?
5. Het verschil is dat MySQL het sowieso sneller is en als je er een timestamp veld van maakt kun je date functies gebruiken op dit veld, omdat MySQL weet dat het om een datum gaat..
0 -0
-0
@Frank
Bedankt ik zal er nakijken :P
@Kees
1. Hierin heb je gelijk, moest even opzoeken, ben geen super genie :P
2. Tja, dat klopt, maar kan het niet zo zijn dat zippen zelf al wat snelheid kost, hierover zal je dus moeten testen of het effect heeft.
3. PHP accepteerd geen cijfers alleen, het zal dan proberen namelijk om je id te hercorrigeren. Al dus zo dacht ik het te lezen in de php manual.
4. Tja ik heb access gekozen als in access time. :) ieder zijn eigen manier he xD
5. Nee z'on verschil bedoel ik niet, ik bedoelde verschil van output, het moet namelijk hetzelfde zijn, zodat de php session handler ermee overweg kan.
Bedankt ik zal er nakijken :P
@Kees
1. Hierin heb je gelijk, moest even opzoeken, ben geen super genie :P
2. Tja, dat klopt, maar kan het niet zo zijn dat zippen zelf al wat snelheid kost, hierover zal je dus moeten testen of het effect heeft.
3. PHP accepteerd geen cijfers alleen, het zal dan proberen namelijk om je id te hercorrigeren. Al dus zo dacht ik het te lezen in de php manual.
4. Tja ik heb access gekozen als in access time. :) ieder zijn eigen manier he xD
5. Nee z'on verschil bedoel ik niet, ik bedoelde verschil van output, het moet namelijk hetzelfde zijn, zodat de php session handler ermee overweg kan.
0 -0
-0
0 -0
-0
Dit script is van Chris Shiflett, een ervaren veiligheidsexpert.
Hij heeft dit script gebruikt in een artikel voor PHPmagazine (http://phpmag.net/), en gepubliceerd op zijn website (http://shiflett.org/articles/storing-sessions-in-a-database).
Hij heeft dit script gebruikt in een artikel voor PHPmagazine (http://phpmag.net/), en gepubliceerd op zijn website (http://shiflett.org/articles/storing-sessions-in-a-database).
0 -0
-0
Dieter heeft volkomen gelijk, het is gewoon geript!
Jammer dat je zelfs niet de moeite hebt genomen om het script nog een klein beetje te verbeteren. In mijn ogen zak je wel redelijk door het ijs, de uitspraken '... heb ik niet gedaan, waarom?' zijn in elk geval eenvoudig te beantwoorden: 'Dat stond niet in het script.'
Jammer.
Jammer dat je zelfs niet de moeite hebt genomen om het script nog een klein beetje te verbeteren. In mijn ogen zak je wel redelijk door het ijs, de uitspraken '... heb ik niet gedaan, waarom?' zijn in elk geval eenvoudig te beantwoorden: 'Dat stond niet in het script.'
Jammer.
0 -0
-0
Delete maar, sorry MIJN EXCUSES AAN ALLEN. Hiermee ben ik diep gezonken en zal ik me nooit meer vergeten als ik hier admin was had ik me allang gebanned, nogmaals mijn excuses.
DELETE DE SCRIPT PER DIRECT SVP.
DELETE DE SCRIPT PER DIRECT SVP.
0 -0
-0
Script hoeft niet verwijderd worden en jij hoeft geen ban, maar als je een script niet zelf geschreven hebt is wet wel de bedoeling dat je je bronvermelding er bij zet...
Zo gaat dat normaal.
Zo gaat dat normaal.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu