Ik ben bezig om de standaard sessie functies te 'herschrijven', mbv session_set_save_handler. Nou vraag ik me af wat beter is, een aparte database maken voor de sessies, of een aparte tabel maken in de database die ook voor de rest van de site wordt gebruikt.
Dat laatste was namelijk in eerste instantie mijn plan, maar doordat in alle voorbeelden die te vinden zijn een aparte database wordt gebruikt, begon ik te twijfelen.
Ligt er maar net aan hoe het zit met de beveiliging.
Stel je maakt bijvoorbeeld allemaal views aan voor dingen die je gebruikt voor op je site. Dan maak je een gebruiker aan die alleen die views kan lezen. En verder geen rechten heeft. Dan is je sessie tabel gewoon veilig omdat ze op deze manier niet bij deze informatie kunnen komen.
Een sessie tabel moet je constant in lezen en schrijven dus het heeft hierdoor weinig nut om geen rechten aan te verlenen. Het is eventueel handig om hier een aparte gebruiker voor aan te maken.
Dit is juist goed hoor, want als je voor de views een aparte gebruiker hebt, maak je die dus ook voor de sessie handler! Op die manier houdt je het dus goed gescheiden!
Wat ik bedoel met geen rechten is: de gebruiker voor de views heeft alleen rechten op de views! En dus niet op de sessie tabellen.
Het sessie gebeuren regel je allemaal aan de kant van de server en dus kan je dit gewoon op een logische en veilige manier verwerken.
Je stopt je sessie tabellen niet in een view! Je views gebruik je voor data die je op je site wilt plaatsen of bijv gebruikers die willen inloggen.
Op deze manier is het dus gewoon goed mogelijk om de sessies te updaten.
Daarnaast regel je gewoon goed de veiligheid omdat je zorgt dat er niet met de sessies gekloot kan worden.
Daarnaast is het wel mogelijk om op views te inserten, deleten en te updaten.
Tenminste, bij PostgreSQL kun je dit realiseren met "rules".
Zal vast ook met MySQL kunnen.
