Description
- Laravel Version: 5.4
- PHP Version:7.1
- Database Driver & Version:
Description:
We're seeing a lot of issues with concurrent requests to the server where session information is lost. Seeing on other forums and discussions on the slack channels, I see a lot of use cases where concurrent requests cause for session data to be lost.
Much of the issues could in my opinion be prevented if not ALL session data is stored at the same time, but if laravel would only update session data for those keys that actually require update.
In our project, for instance, we are having a polling mechanism that asks the server for the current session state; each such request however SAVES the session data in its entirety. If - at the same time - the user is doing a rest request to authenticate, or to log out, or basically to do any action that might require session data to be updated, we're having a lot of risks of the requests to impact one another.
request A: POST/auth/login
request B: GET /session/state
if both these requests are sent to the server, B updates the session because user logs in, but request A was already started, and saves the session after that, the authentication information is lost, and the user is logged out again, even though he just authenticated.
I think it's a "big" change, but it would be better if only session data that is changed, is being saved. at this time, the entire session data is always being stored, which isn't desirable.
Adding a key to the method that stores data will be breaking for all drivers, and may impact existing users that have implemented drivers. therefore, I believe it would be advisable that laravel checks the driver method using reflection to see if the driver already supports key-based storing, and if not should log a warning and fallback to old mechanism. In later laravel version (6?), we could deprecate the old way of dealing with it.
Any thoughts?