Disappeared session variables?

[Yoeri Nijs]

Hi all!

Recently, I've discovered some strange behaviour regarding variables that are stored in the current session. I'm not a PHP guy in daily life (mostly TypeScript), so maybe I am doing something wrong here... Hopefully, one of you can explain what is happening here.

The thing is: when a user is logging in in my application, I retrieve some user data from the database and store this data in the current session. By doing so, I can just pick some general information such as the current name from the session, instead of going to the database over and over again.

This is the general idea (very simplified):

$userId = Base::instance()->get('POST.id');

$userModel = new UserModel();

$user = $userModel->getById(userId );

if (!$user->dry()) {

  // Login logic...

  // Setting some commonly used vars

  Base::instance()->set('SESSION.firstName', $user->firstName);

  ... 

}

However, after some time, I notice that the session vars are turned out to be empty. So, it seems that something is clearing them. Is this as expected and is my implementation wrong here?

Initially, I though that the garbage collector was removing some stuff here, but I guess that is not what actually happening here; I've changed the following gc_ vars in the application startup script with ini_set to increase the session lifetime tremendously, but that does not help (gc_maxlifetime, gc_probability, gc_divisor). 

[ved]

Hi,

If you're using Debian (and I'm guessing Ubuntu or any other Debian derivates) as your operating system, then the garbage collector is actually a couple of systemd unit files (phpsessionclean.service and phpsessionclean.timer) that clean up the session folder and expires the sessions occasionally and that may not always obey the gc_ parameters depending on your configuration.

If you're using any of the F3 session handlers (the cache one or any of the db handlers) then it's possible that your session is getting destroyed if you are changing your useragent or ip. (for example, using Chrome's developer tools mobile view changes the user agent and F3 destroys the session due to the user agent change).

Not sure any of those are  what's causing it but that's all I can think about for now. Feel free to post any more code or findings you may encounter.

Cheers.

[Paul Herring]

> If you're using any of the F3 session handlers (the cache one or any of the db handlers) then it's possible that your session is getting destroyed if you are changing your useragent or ip. (for example, using Chrome's developer tools mobile view changes the user agent and F3 destroys the session due to the user agent change).

If you want to check for that, override the `onsuspect()` call to log something and if you don't want the session destroyed, return true from it. See the example at https://fatfreeframework.com/3.7/session#onsuspect

The output of 

  error_log("Cookie:" . print_r(var_dump(session_get_cookie_params(), true)));

may also be instructive (specifically the lifetime member.)

--
-- You've received this message because you are subscribed to the Google Groups group. To post to this group, send an email to f3-fra...@googlegroups.com. To unsubscribe from this group, send an email to f3-framework...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/f3-framework?hl=en
---
You received this message because you are subscribed to the Google Groups "Fat-Free Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to f3-framework...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/f38ae383-90d8-4871-a36d-f867025e3014n%40googlegroups.com.

--

PJH

[ikkez]

When the session became empty, usually the user is logged out then. So you should login again. This can happen when the cookie expired, i.e. when closing the browser an reopening it.

[Yoeri Nijs]

Thanks, all!

My findings:

- I am using the default FatFree session implementation (no db or Jig);

- Currently, I have a custom implementation of the onSuspect method. It only returns false (invalidates) the current session if the ip is different, which is not the case;

- I am using the official PHP Docker image (7.4.27-apache-buster) which is based on Debian. However, there seems no phpsessionclean.service and phpsessionclean.timer available in the container itself.

- The cookie is bound to the current session, according to the application tab of dev tools. So the cookie should not expire after some minutes;

- It depends from time to time when the session is destroyed. Sometimes it is rather quick, other moments not. Somehow it seems that inactivity plays a part in it. If I leave the session open for some minutes without doing anything, the session is destroyed. Not sure if this is definitely the case.

- The session_get_cookie_params() returns:  array(6) { ["lifetime"]=> int(0) ["path"]=> string(1) "/" ["domain"]=> string(13) "<my domain>" ["secure"]=> bool(true) ["httponly"]=> bool(true) ["samesite"]=> string(3) "Lax" } bool(true)

- Furthermore, i've included the session parameters from phpinfo();

- In setup phase of the app, I am setting the following. I am aware of the high values here, but I am just trying to debug this.

ini_set("session.gc_maxlifetime", 60*60*24*1); // One day
ini_set("session.gc_probability ", 1);
ini_set("session.gc_divisor ", 5000);

Op maandag 25 april 2022 om 23:52:12 UTC+2 schreef ikkez:

[Yoeri Nijs]

Well, it turns out that the ini_set values should be strings, not numbers :) For gc_divisor, for example, numbers will be ignored. There was no exception whatsoever. It just fell back on default behaviour.

Op woensdag 27 april 2022 om 17:16:58 UTC+2 schreef Yoeri Nijs: