Van de week heb ik de map waar de session cookies op de server bij mijn host worden opgeslagen gewijzigd naar een map waar ik zelf toegang toe heb (buiten de root). De reden hiervan was dat het heel soms gebeurd dat een session cookie corrupt raakt en je dan de helpdesk moet vragen de session te verwijderen voordat je door sessions beveiligde gedeelte van de website weer werkt. Nu kan ik dat in geval van nood zelf. (Dit gebeurd overigens alleen tijdens development, als er heel veel geupload en gerefreshed wordt, heb het nog nooit in een live omgeving meegemaakt of gezien)
https://secure.servage.net/wiki/Session

Anyway, nu valt me het volgende op. Als ik een sessie verwijder met session_destroy(); dan wordt de session cookie helemaal leeg gemaakt, maar het bestandje zelf blijft wel staan. Hoort dat zo? Ik ging er altijd van uit dat bij session_destroy() gewoon alles verwijderd zou worden...

De permissies van de map waarin de session cookies opgeslagen worden staan op 777 en de eigenaar ben ik.
Nee, heb ik niet, ik heb gewoon shared. Ik koos daar ooit voor omdat je bij het shared pakket véél (oneindig) meer dataverkeer hebt en bovendien meer opslag. Tegenwoordig is dat niet zo belangrijk meer voor me, misschien moet ik eens mijn pakket veranderen. De laatste tijd wel meer beperkingen ontdekt, zoals geen OpCache. (Wat voor drupal8 en laravel wel prettig is)
@vast IP, volgens mij moet het mogelijk zijn om iets slims te doen met enkel de user agent en een random string met voldoende "entropie" zoals aangehaald in een ander draadje.

Reageren