You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: