Level 75
See if a bug has been reported for this, seems a while back someone had something similar happen.
Jun 23, 2015
7
Level 1
Session Issues
I would appreciate any help anyone can give on an issue I am having with sessions on a 5.0 project. Currently, I am using file based sessions. Once the session has been created, I cannot add, change or destroy a value in the session. When I try to destroy a value in the session, it goes away for the remainder of the script, but it is not changed in the file, and shows up again when the page is refreshed! If I try to change a value, the change is not written to the file, and the original value shows up again.
Level 32
give a try after changing the file permission of storage folder to 755.
Level 1
I do not see anything in issues on github, unless they are logged somewhere else.
This almost seems like a permissions issue, but this behavior is the same on my local machine and the development server. And I THINK the permissions are correct on my local machine: the sessions directory is read/write/modify/read&execute for every user.
PHP sessions are working normally. We may be forced to use those instead of laravel's session manager unless we can get this resolved soon!
Level 1
Hi Milon,
That does seem like it should be the problem, but it does not make a difference. Unless I am doing it wrong - I tried chmod -R 755 sessions.
Level 75
Make sure that folder is writable also.
Level 65
Sounds like a one off problem, have you tried using something other than file for sessions?
Level 1
I tried to change to database sessions, and could not get laravel to use the session table.
Set up a sessions table using artisan, changed config\session.php to: 'driver' => env('SESSION_DRIVER', 'database'), and the system ignored these changes.
We are having one other issue which may be related. Laravel is caching the views and will not update them, so we are having to delete the storage/framework/views files in order to view changes. This is happening on my local machine and on the server. Just started this behavior, and I am not sure why. We just reached the point with our application that we needed to introduce sessions. If the session problem has existed longer, we would have been unaware of it.
Please or to participate in this conversation.