Database Sessie Handler

Door CB2thephp , 15 jaar geleden, 3.242x 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

  1. database-sessie-handler

 

Er zijn 18 reacties op 'Database sessie handler'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Niels Janssen
Niels Janssen
15 jaar geleden
 
0 +1 -0 -1
En hoe herken jij nu gebruikers?
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
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!
Ivo van Beek
Ivo van Beek
15 jaar geleden
 
0 +1 -0 -1
Waarom $_SERVER als opslagruimte gebruiken voor een gebruikersnaam en wachtwoord?
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
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.
Henk
Henk
15 jaar geleden
 
0 +1 -0 -1
Ik snap je niet helemaal, maar als je toegang hebt tot PHP, kun je toch ook gewoon een bestandje
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php print_r ( $_SERVER ) ?>
maken?
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
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.
Kees Schepers
kees Schepers
15 jaar geleden
 
0 +1 -0 -1
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:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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;
?>


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)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
$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.
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
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.
Frank -
Frank -
15 jaar geleden
 
0 +1 -0 -1
"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.
Kees Schepers
kees Schepers
15 jaar geleden
 
0 +1 -0 -1
@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..
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
@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.
Kees Schepers
kees Schepers
15 jaar geleden
 
0 +1 -0 -1
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
var_dump((int)'blaat');
?>


Dat zal 0 printen..., of bedoelde je dat niet?
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
Ja zoiets bedoelde ik.
Dieter
Dieter
15 jaar geleden
 
0 +1 -0 -1
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).
Frank -
Frank -
15 jaar geleden
 
0 +1 -0 -1
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.
CB2thephp
CB2thephp
15 jaar geleden
 
0 +1 -0 -1
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.
Hipska BE
Hipska BE
14 jaar geleden
 
0 +1 -0 -1
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.
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Sander
Sander
14 jaar geleden
 
0 +1 -0 -1
Is het mogelijk om mensen uit teloggen die in de database staan?

Om te reageren heb je een account nodig en je moet ingelogd zijn.

Inhoudsopgave

  1. database-sessie-handler

Labels

  • Geen tags toegevoegd.

Navigatie

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.