Multiuser: Blank screen after leaving it logged in for a while

[lbdroid]

This situation occurs after the client has been logged in for some time, without any activity. A client refresh will yield a GRAY screen, with a black line separating the header section from the body, but no data or buttons present.

In this situation, the $_SESSION array has two keys set; login = 1, identifier = ....
In addition, the role mode selection in php/api.php falls into GUEST mode, which is inconsistent with login = 1.

At this point, forcing it back into the same "role" that it was previously logged in as will return the functionality to normal. I do this by replacing the entire "if (admin) else if (user) else" block with the following;

$_SESSION['role'] = "admin";
define('LYCHEE_ACCESS_ADMIN', true);
$admin = new Admin($database, $plugins, $settings);
$admin->check($fn);

So what is happening, is it is losing the "role" variable of the session.

I will look into this more tomorrow.

[lbdroid]

We are actually losing three of the session variables; username, userid, and role.

[lbdroid]

Ok, this problem happens when the session file gets wiped from the server. I.e., /var/lib/php/session/sess_something. When that happens, the server generates a new session with the same ID, based on the session variable being sent in from the browser. The newly recreated session is missing some of the variables.

[lbdroid]

I've been able to improve the situation slightly.
Putting the following into api.php just after running session_start();

if(isset($_SESSION['login']) && !isset($_SESSION['role'])){
        $_POST['function'] = "Session::logout";
}

On the client side, the gray screen problem still happens, but it is cleared to a "logged out" state when you hit refresh. So a definite improvement, as it is no longer necessary to clear the session cookie manually.

[lbdroid]

The problem comes from this commit; 24444de

In order for that to be able to work, you would need to feed back all of the variables that are stored in the session. In addition to what it is able to recover, that means username, userid, and role. However, given that username and role can be looked up from the database knowing userid, userid itself should be adequate.

[lbdroid]

Would this be the first commit related to multi-user?
2c72b8b

[Aidenir]

@lbdroid Yes I think that is the first commit specifically related to the multi-user functionality, however I can't remember if the multi-user stuff is in some way tied to the session stuff I did before that, in 24444de