harikt
commented
8 years ago Hi @mivanov93 ,
You can use $_SESSION even if you are storing session in database or any layer. What you need is only register http://php.net/manual/en/function.session-set-save-handler.php .
Recently I had to think of a way to persist the authentication tokens(basically sessions), but I don't see why everyone is about using the $_SESSION. Now I know it's easy to use, but isn't it bad for performance?(While some may say we can use SQL, storing a blob object in there is ugly). So why do we need to use $_SESSION - we also have the problems of read/write sync as well, since sessions are like mutexes and we must explicitly close them to allow multiple concurrent requests.(No streaming data otherwise either).
So, since we have a database anyway, isn't it better to just put our sessions in there? But if we put them there - there is the limitation, we have certain fields and we don't just serialize objects and mash them up. Bad for performance, unmanageable and ugly. Even worst - if our user has been changed, we must first get our $_SESSION and then ask the database about it. Bad.
So my idea is - to add an authentication that is a mix of both Session and Remember me - a normal cookie whose value references a session in our database. So when logging in - if a user selects remember me, we can just set a field in there to true. So if he is inactive for a long time, the system may boot him out, but we can still get his data from the session and autofill his username/etc.
But when using an Rest API, rather than depending on a cookie, we should make it so that a header can be used.(which will save us from XSRF and Cors attacks if Cors is enabled). For normal, non-rest api based applications, forms can contain a hidden XSRF field. But then again - perhaps for a Rest API - one should just use a stateless authentication sending the user and pass plus a nonce every time(kinda like WSSE).