Level 70
@ligonsker What is your session driver?
If it is File, can you make sure that it has the right permission?
For example:
chmod -R 775 storage
1 like
Jul 25, 2024
12
Level 8
Buggy session behavior
Hi,
I deleted the previous post because I realized it's not just the session helper.
I have a weird problem where sometimes sessions won't be stored, either using the helper or the $request->session()->put(...); method.
For example, I have a simple controller method that returns a view and also stores a session if it doesn't exist yet:
public function my_view(Request $request)
{
if(!$request->session()->has('my_session')) {
$request->session()->put('my_session', 'default_value');
}
.. some code ..
return view('my_view');
}
Then, I am using this session on another method, which is called by clicking on a button on the same view above:
public function some_action(Request $request)
{
$my_session_value = $request->session()->get('my_session'); // null
// need to use $my_session_value but it's null sometimes!
}
But the session value returns null, and after refreshing the view a few times, or clicking the button that updates that session value, it would work.
And it doesn't happen all the time, but it does happen many times after the initial page load
What could cause that?
Level 50
You should post your actual code, not pseudo code. Otherwise it's impossible to tell what's wrong.
2 likes
Level 80
1 like
Level 6
One thing that might cause it is setting the session somewhere else
public function my_view(Request $request)
{
if(!$request->session()->has('my_session')) {
$request->session()->put('my_session', 'default_value');
}
// ok you have set you have tested for NOT having a 'my_session' key and given it a value but
// what if you have set it somewhere else and not given it a value. that would cause your behaviour
.. some code ..
return view('my_view');
}
1 like
Level 8
@tisuchi yes it's file and the permissions are correct
@jussimannisto, @martinbean Sorry I don't post the actual code, it's in internal system and I would have to manually copy a lot of code😅. nice gif btw 😂😭🤣
But, I did notice that in my pseudo code I made something that is fundamentally different than the actual code: in the actual code the sessions are set using the array notation (using dot while setting):
public function my_view(Request $request)
{
if(!$request->session()->has('my_session.key1')) {
$request->session()->put('my_session.key1', 'default_value1');
}
if(!$request->session()->has('my_session.key2')) {
$request->session()->put('my_session.key2', 'default_value2');
}
.. some code ..
return view('my_view');
}
so now if I dump the session data using dd($request->session()->all();, I can see it's an array:
"_token" => "galuDY....."
"_flash" => array:2 ["old" => [], "new" => []]
"_previous" => array:1 ["url" => "https://example.com/"]
"auth" => array:1 ["password_confired_at" => ...]
"my_session" => [] // <--- it's empty sometimes
Could the issue be that the code is using put and get on the array notation which causes the issue? And in this case, push and pull should be used instead, or, change the session names to not use dot (.) when setting the session values?
Level 80
I did notice that in my pseudo code I made something that is fundamentally different than the actual code
@Ligonsker Which is why is irritates the hell out of me when people go, “I have problem with X. Here’s Y instead”. If you don’t show the actual code then you’re potentially hiding the actual issue, and people waste time trying to debug something where there isn’t even a problem… because it’s code someone’s made up.
Could the issue be that the code is using
putandgeton the array notation which causes the issue? And in this case,pushandpullshould be used instead, or, change the session names to not use dot (.) when setting the session values?
You should only be reading/writing sessions values as the Laravel docs demonstrate. If you and/or colleagues are just making up your own way of working with the session, i.e. treating it as an array, then you can’t be surprised when things don’t work as intended.
1 like
Level 122
@Ligonsker be careful using dd. It causes session data to not be saved as the request terminates prematurely
1 like
Level 8
@Snapey thank you, yes, I only use dd() after storing the session in another request that was not interrupted, the dd was later used just for reading and on a separate request
Level 8
@martinbean thank you, yes I understand and sorry about that, I just really couldn't copy the actual code in this case. And also, it really does seem like they did whatever they wanted in this case 😅. I am going to change the code and see if it works.
Level 8
Update: After changing the code to use the correct syntax, I am stil facing this issue: Many times the session would be null even though the code is setting the correctly as per documentation. There is something buggy in the session I think
It would still randomly stay null even though I set everything as should be
Still can't tell why it's happening.
It might also be caused by the fact that I'm using IIS and some application pool which isn't playing well with PHP and Laravel? Not sure anymore (or maybe using the non-thread safe of PHP).
Update #2:
I do Log::debug to output the session values, I notice that if I get the value of the set session during the request:
if(is_null(session('my_session_key'))) {
Log::debug("Null");
$request->session()->put('my_session_key', $key);
}
Log::debug("Session after setting value: " . $request->session()->get('my_session_key');
Then it does output the key "Session after setting value", but then if I refresh the page again, it still goes inside the is_null check, which means something interrupts the session saving in the middle.
(It does not happen with the same code on XAMPP in the local dev, only on the Windows servers)
Level 8
Update:
I found in an old post that the session facade has a save() method which means it should save the session immediately and not wait for the end of the lifecycle - is that true?
because when I added that after the put() method, the problem seem to have been solved!
But the save() method isn't in the official docs: https://laravel.com/docs/10.x/session
public function my_view(Request $request)
{
if(!$request->session()->has('my_session')) {
$request->session()->put('my_session', 'default_value');
$request->session()->save(); // <-- added this
}
.. some code ..
return view('my_view');
}
If that really solved the problem - what could be the cause for the missing keys issue that happens sometimes? Because the script isn't interrupted anywhere as the page fully loads. So I couldn't find anywhere a reason for the session not to be saved
Level 8
Update: I was wrong in my previous comments: It is NOT related to the app being on a Windows Server, because I just noticed it happens locally on XAMPP as well (and the above addition of save() fixes it)
Please or to participate in this conversation.