Reacties op het script Custom database-sessiehandler
|
|
 Gepost op: 04 juli 2011 - 13:48 |
|
|
|
Erelid
|
Engelse code en een nederlandstalige database-structuur.. brrrr  |
|
|
|
|
| Gepost op: 04 juli 2011 - 18:43 |
|
|
|
Erelid
|
Als je verstand hebt van PHP maak je dit zelf  |
|
|
|
|
| Gepost op: 05 juli 2011 - 15:49 |
|
|
|
Erelid
|
Dat geldt voor alle scripts, vandaar ook mijn eerste bemerking, ik breek zeker je script niet af, ik vind het gewoon een foute mentaliteit om Nederlands en Engels door elkaar te gaan gooien in code, uiteindelijk is het de bedoeling dat iemand hier iets van leert  |
|
|
|
|
| Gepost op: 15 juli 2011 - 14:31 |
|
|
|
PHP ver gevorderde
|
Update @ 15/7
Opgemerkt dat ik een typo heb gemaakt in het script, mocht je het gebruiken en opmerken dat je sessies niet geupdate worden. Kopier/plak het script dan opnieuw |
|
|
|
|
| Gepost op: 11 november 2014 - 14:57 |
|
|
|
Moderator
|
Citaat: Het grote voordeel hiervan is dat je niet met problemen van shared hosting zit
...maar wat ook vrij eenvoudig op te lossen is door middel van het instellen van een persoonlijke directory voor het wegschrijven van sessie-bestanden (via de functie session_save_path() of via ini_set() of via .htaccess).
Tenzij er nog andere issues zijn?
Voor de rest lijkt dit script even (on)veilig als "normaal" sessie-gebruik; beide varianten hebben toegang tot de bijbehorende data via een cookie die de "sleutel" bevat.
Ik weet niet of dit veilig genoeg is. Stel dat iemand het voor elkaar krijgt om ergens document.cookie af te drukken en dit door te geven aan een externe bron dan is effectief je sessie gestolen. Misschien is het een idee om een IP-controle toe te voegen? Dat of ik zou je cookie laten verlopen zodra je je browser sluit (expire parameter met waarde 0).
Oh en ik zou een vierde parameter (path) toevoegen, waarschijnlijk wil je dat je sessie op heel het domein geldig/toegankelijk is - op dit moment is deze alleen geldig in het pad waar je de sessie hebt gestart. (Geef deze parameter de waarde '/' om de sessie(cookie) op het hele (sub)domein actief te laten zijn) |
|
|
|
|
| Gepost op: 23 juni 2016 - 14:38 |
|
|
|
Moderator
|
Ook combineert dit mogelijk twee zaken:
sessie authenticatie en sessie afhandeling.
Voor het laatstgenoemde is daar trouwens session_set_save_handler.
Op die manier blijf je op een "native" manier werken met sessies (middels session_start(), $_SESSION en andere session_-functies). Hoe dit verder onder water wordt afgehandeld (bijvoorbeeld via een database in plaats van op grond van bestanden) is abstractie, hier merkt een gebruiker programmeur verder niets van.
Andere observaties:
* twee tabellen voor sessies? Waarom niet 1 tabel met een (TEXT) kolom voor de sessiedata?
* werkt nu met simpele key-value paren, hoe ga je om met geneste arrays? Je zou eea kunnen serialiseren, but then again, dit wordt al automatisch geregeld als je gebruik maakt van session_set_save_handler |
|
|
| Enkel aanvullende informatie, vragen en antwoorden op vragen zijn welkom. |
|
|
|
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
