Sessie niet opgeslagen op subdomein

I'm confused.

Wat hebben session cookies (client side) te maken met de fysieke sessie bestanden (server side)?

Het gaat ook om een secure domein (4e parameter)?

Waaruit blijkt dat de sessies niet wordt gestart, of hoe (en waar) controleer je dit?

Waarom geen sessie systeem aan de hand van een key/Database. Bijvoorbeeld naar een halfuur geen activiteit de sessie eruit gooien. Zoiets als:

table_sessions:
[sessie_id] - Unieke id
[sessie_user_id] - De gebruikers id
[sessie_key] - De unieke sessie key
[sessie_time_update] - De laatste activiteit van de user.
[sessie_time_start] - Wanneer de sessie begonnen is.

Ongeveer zo, en aan de hand van sessie_time_update zou je dan de user na een halfuur eruit kunnen gooien.

Wat betreft sessies op backend van de client weet ik niet of dit zal werken met $_SESSION, omdat backend niet open blijft en dus de sessie vervalt. (Cookies zou misschien kunnen, geen ervaringen mee)

Citaat van ThomasBlom

Nadat ik ben ingelogd, navigeer ik naar een andere pagina. Daar krijg ik geen session als resultaat.

Bevindt deze andere pagina zich in het pad /tmp, oftewel, navigeer je naar iets van de vorm http(s)://domain.com/tmp? Want dat (die, en onderliggende directories) is het geldigheidsdomein wat je instelt voor je sessie-cookie middels session_set_cookie_params(). Daarbuiten "bestaat" deze niet.

Je zou altijd je cookies kunnen inspecteren via je browser. Grote kans dat daar dan gewoon een sessie-cookie tussenstaat met path "/tmp".

Citaat van ThomasBlom

Maar wanneer ik een POST request naar de API stuur, waar dezelfde code wordt uitgevoerd, wordt dit niet opgeslagen.

Dan zou ik daar eens naar kijken :).

Citaat van ThomasBlom

De cookie zou je ook zelf kunnen maken. De kans dat je een session_key goed hebt gegokt die ook nog geldig is, is nogal klein. Toch is die aanwezig denk ik.

Daarom zul je aanvullende voorzieningen moeten treffen waarmee je met grotere zekerheid kunt stellen dat je met een zekere gebruiker van doen hebt. Enkel een sessie-id lijkt mij sowieso niet echt verstandig/voldoende voor deze check.

Misschien kun je op een of andere manier makkelijk gebruik maken van het feit dat je HTTPS gebruikt - al het dataverkeer wordt encrypted verstuurd/ontvangen. Je zult dan waarschijnlijk wel (extra) informatie moeten onthouden zodat je dingen kunt controleren, dus ik denk dat je dan toch (deels) aangewezen bent op de gebruikmaking van een database.

Ook lijkt het mij verstandiger om elke page-access de database te raadplegen om te kijken wat de status van een gebruiker is. Indien je deze informatie (rol, privileges etc.) in je sessie opslaat kun je hier niet direct op acteren, maar zul je moeten wachten totdat de sessie getimeout is of dat een gebruiker uitlogt. Of je moet functionaliteit hebben die iemand geforceerd uitlogt, maar dat lijkt mij de verkeerde insteek (borduurt verder op een andere tekortkoming: het "blijven hangen" van informatie in je sessie).

Dit lijkt me allemaal nogal complex.
http://culttt.com/2013/02/04/h…p-sessions-to-a-database/
Sessie rechstreeks opslaan in de database.

Misschien kun je iets van Symfony Sessions. Je kunt dan zelf bepalen waar je de sessie opslaat d.m.v. een configuratie, bijvoorbeeld in de database.

Citaat van stijnhau

Dit lijkt me allemaal nogal complex.
http://culttt.com/2013/02/04/h…p-sessions-to-a-database/
Sessie rechstreeks opslaan in de database.

Dat artikel, evenals het artikel waar daarin naar verwezen wordt, is interessant maar er zijn wel enkele "caveats", gotcha's en (mogelijk) enkele regelrechte fouten waar je op moet letten.

Indien gewenst kan ik (hier of via PM) inhoudelijk nog veel meer over zeggen, maar het voornaamste wat mij tegenstaat in de bovenstaande implementatie is het volgende:

Ik houd er niet van als mijn klasses "op scherp" staan, in die zin dat er allerlei zaken automatisch worden uitgevoerd bij de creatie van een object. Wanneer een object aangemaakt wordt zouden er enkel zaken geïnitialiseerd moeten worden, maar NIET uitgevoerd! Na afloop van de initialisatie van een object zou dit object enkel "klaar voor gebruik" moeten zijn, maar verder nog niets "gedaan" moeten hebben. In de constructor van het object gebeuren er twee dingen die ik op een andere manier en op een andere plaats zou aanpakken / regelen:

• de start van een sessie
• het opzetten van een database-connectie

Ik wil zelf bepalen wanneer ik mijn sessie start. De sessie-handler zou enkel in de implementatie van het sessie-management moeten voorzien, maar niet eigenhandig moeten besluiten wanneer de sessie wordt gestart. Ik zou session_start() dan ook verwijderen uit de constructor.

Daarnaast lijkt het mij beter dat je een bestaande database-connectie doorgeeft aan de constructor. Het is niet de taak van de sessie-handler om een andere/tweede connectie op te zetten met een database... Daarnaast is het opzetten van een (tweede) connectie een dure operatie en kan mogelijk voor problemen zorgen met de ondeelbaarheid van querybatches (transacties).

En tot slot (observatie): het hele doel van die class is dat deze het sessie-management onder water regelt en dat je sessie-gerelateerde code op de ouderwetse manier blijft gebruiken (de aanroep van session_-functies en het gebruik van $_SESSION). Het is dus eigenlijk helemaal niet de bedoeling dat je iets doet via het object van die klasse, het object zou dan ook niet beschikbaar moeten zijn.

Initialisatie van deze functionaliteit zou er dus min of meer als volgt uit moeten zien:

<?php
// zet hier ergens EENMALIG je database connectie op
// $db = ...


// laad je custom session handler ZONDER $obj = new ...
// de instantie dient immers niet rechtstreeks benaderbaar te zijn
// geef database-object door aan de constructor
new MySession($db);


// start sessie op de oude manier
session_start();


// nu kun je $_SESSION en session_-functies gebruiken zoals voorheen
// ...
?>

Citaat van FangorN

Dat artikel, evenals het artikel waar daarin naar verwezen wordt, is interessant maar er zijn wel enkele "caveats", gotcha's en (mogelijk) enkele regelrechte fouten waar je op moet letten.
Indien gewenst kan ik (hier of via PM) inhoudelijk nog veel meer over zeggen, maar het voornaamste wat mij tegenstaat in de bovenstaande implementatie is het volgende:

Ik houd er niet van als mijn klasses "op scherp" staan, in die zin dat er allerlei zaken automatisch worden uitgevoerd bij de creatie van een object. Wanneer een object aangemaakt wordt zouden er enkel zaken geïnitialiseerd moeten worden, maar NIET uitgevoerd! Na afloop van de initialisatie van een object zou dit object enkel "klaar voor gebruik" moeten zijn, maar verder nog niets "gedaan" moeten hebben. In de constructor van het object gebeuren er twee dingen die ik op een andere manier en op een andere plaats zou aanpakken / regelen:

• de start van een sessie
• het opzetten van een database-connectie

Ik wil zelf bepalen wanneer ik mijn sessie start. De sessie-handler zou enkel in de implementatie van het sessie-management moeten voorzien, maar niet eigenhandig moeten besluiten wanneer de sessie wordt gestart. Ik zou session_start() dan ook verwijderen uit de constructor.

Daarnaast lijkt het mij beter dat je een bestaande database-connectie doorgeeft aan de constructor. Het is niet de taak van de sessie-handler om een andere/tweede connectie op te zetten met een database... Daarnaast is het opzetten van een (tweede) connectie een dure operatie en kan mogelijk voor problemen zorgen met de ondeelbaarheid van querybatches (transacties).

En tot slot (observatie): het hele doel van die class is dat deze het sessie-management onder water regelt en dat je sessie-gerelateerde code op de ouderwetse manier blijft gebruiken (de aanroep van session_-functies en het gebruik van $_SESSION). Het is dus eigenlijk helemaal niet de bedoeling dat je iets doet via het object van die klasse, het object zou dan ook niet beschikbaar moeten zijn.

Initialisatie van deze functionaliteit zou er dus min of meer als volgt uit moeten zien:

PHP

<?php
// zet hier ergens EENMALIG je database connectie op
// $db = ...


// laad je custom session handler ZONDER $obj = new ...
// de instantie dient immers niet rechtstreeks benaderbaar te zijn
// geef database-object door aan de constructor
new MySession($db);


// start sessie op de oude manier
session_start();


// nu kun je $_SESSION en session_-functies gebruiken zoals voorheen
// ...
?>

Toon Meer

Toon Meer

Het meeste geef ik je gelijk in enkel die seesion_start niet oùdat als je die class include je sessies wilt gebruiken.
Anders moet je die class niet includen.
Ook is er kan ik niet echt een reden bedenken om dit niet rechtstreeks te wensen.

Citaat van stijnhau

Het meeste geef ik je gelijk in enkel die seesion_start niet oùdat als je die class include je sessies wilt gebruiken.
Anders moet je die class niet includen.
Ook is er kan ik niet echt een reden bedenken om dit niet rechtstreeks te wensen.

De class verzorgt de afhandeling /verwerking van sessie-opslag. Dit alles gebeurt onder water. Wanneer je session_-functies aanroept of $_SESSION gebruikt heb je er geen weet van hoe dit achter de schermen geregeld wordt en dit hoeft ook niet want dit is in zekere zin abstractie. Wat mij betreft is het dan ook niet aan de klasse om bij het instellen van het type afhandeling van sessies het startsignaal te geven voor het starten/voortzetten van een sessie zelf.

Vergelijk het met de default implementatie van de sessionhandler: daar roep je ook altijd eerst session_start() aan. Pas je deze default session handler aan dan zou dat voor de overige code niet uit moeten/mogen maken. De session handler zelf zou dan ook niet eigenhandig een sessie moeten starten, deze schrijft enkel voor hoe een en ander administratief (en onder water) wordt afgehandeld.

Session handlers zouden ook "vrij inwisselbaar" moeten zijn zonder dat deze van invloed is op andere code. Ook om die reden hoort session_start() niet in de handler zelf thuis: dit zou namelijk inhouden dat je voor sommige implementaties session_start() in andere code zou moeten toevoegen en in andere implementaties achterwege kunt laten. In dat geval zou de ene handler niet zonder meer uitgewisseld kunnen worden voor een andere.

Long story short: het starten/voortzetten van een sessie regel je simpelweg niet in de handler zelf omdat dat niet de taak is van een session handler :p.

Oh, nog een argument: je zou sessie-instellingen dan ook in de constructor moeten opnemen/doorgeven (of moeten instellen voordat je een object creëert) omdat je deze voor het starten van de sessie moet instellen. Hiermee leg je een additionele eis op aan de volgorde waarin dingen geregeld moeten worden. Het wordt dan allemaal steeds minder transparant/intuïtief en gaat ook voorbij aan de scope van wat een session handler zou moeten doen...