Welcome Guest, Not a member yet? Register   Sign In
A session on $_SESSION
#8

(This post was last modified: 07-06-2021, 03:11 PM by Gary.)

(07-03-2021, 09:02 PM)InsiteFX Wrote: This is how I load my sessions, ignore the helper files.
PHP Code:
<?php

namespace App\Controllers;

use 
CodeIgniter\Controller;
use 
CodeIgniter\HTTP\RequestInterface;
use 
CodeIgniter\HTTP\ResponseInterface;
use 
CodeIgniter\Services;
use 
Psr\Log\LoggerInterface

Thanks InsiteFX, I've tried your code, character-for-character the same in my code, but I'm still intermittently loosing the session.

I've tried dozens of things, but for some reason, I still can't find the cause or even a duct-tape & chewing-gum patch (without knowing the root cause) for the $session going awol at what appears to be completely random times.

I've snooped around the framework code, and found the source function of the session (so I've bypassed the invocation via the \App\Config\Session route, and appear to not require the 'use' link in the Controller's/Models/Library headers now because it's a framework base service):
Code:
$session = \CodeIgniter\Config\Services::session();

So now I have this bit of code stuck in the first place in every namespace where $_SESSION[' '] is accessed... and it all works perfectly for a few minutes or perhaps 30 minutes... regardless if the signed in user does anything on the server or not.  After this the session is lost, and they unedpectedly find themselves on the landing page.

From my experimentation, I find that most of the time the session appears to go missing in the Filters (the first place the session is used in any of the before Filters)... not in the BaseController (though it has also been observed to go missing there on one or two times out of hundreds of lost-in-Filter disappearances).

Currently, for the debugging, I have some JavaScript on the client polling the server every two seconds (to get the session loss to happen faster).  The server responds with a new CSRF token, and a status code in a single byte character specifying flag status' (like new message alerts etc).  The CSRF token and status code are presented as a single string of characters.

The specific poll code results in the poll being sent though the before Filters, to the central 'controller', which does nothing besides a return; for this poll code.  The reply is automatically sent back via the after Filters that generate the CSRF token and attach the status code byte.

Having spent hours on this, I've double-checked the already double-checked settings, and all the other suggestions of permissions and avoiding redirects, and using session_write_close(), even though these are now done automatically by PHP (thanks includebeer).

I've also tried checking and forcing things that are already done (by Services:: session()) with a variety of things similar to:
Code:
if (!session_id()) session_start();
where $_SESSION is going missing, and even forcing it to be a shared session, for what that's worth.

I've tried increasing the memory_limit in the PHP ini file, and several changes, one change at a time in the Apache configuration files, but have ended up back with what was originally used (with no difference being observed in the session being lost with any of the changes).

Because I'm using a MPM (multi-processing module (multi-threaded)) build of Apache, it uses PHP-FPM (which requires configuration as a proxy), and I've tried with and without:
Code:
# RequestHeader unset Proxy early
// and
#RequestHeader unset Proxy
...just in case this was causing PHP to be lingering when closing the session between calls. No observable difference was found.

I've checked the log files (CodeIgniter v4.1.3, Apache v2.4.43 and PHP v7.4.6 (log_errors is On, display_errors is On, error_reporting = E_ALL))... though, because there isn't really an error, I don't expect to find anything relating to this problem (?).

As a duct-tape & chewing-gum fix, I even tried sticking a conditional session_write_close(); at the start of the BaseController in case it somehow hadn't been closed properly in the last call, but that also doesn't stop it from being lost.

There's not a lot of code to post to illustrate what I'm doing... and it's pretty much the same as InsiteFX's code... so I'm at a loss as to what to try next.

Any suggestions or general direction-pointers would be greatly appreciated.

Thanks.



An additional question:  I presume BaseController is called and executed prior to any of the Filters being invoked... could someone please confirm this?

If this is indeed the case, is there a reason that would cause the session be lost only in the Filters and not in the BaseController (which also uses the user's session to set the default location, timezone and several other user-specific customization overheads)?
Reply


Messages In This Thread
A session on $_SESSION - by Gary - 06-24-2021, 04:06 PM
RE: A session on $_SESSION - by superior - 06-25-2021, 07:50 AM
RE: A session on $_SESSION - by Gary - 06-26-2021, 03:26 PM
RE: A session on $_SESSION - by InsiteFX - 06-26-2021, 08:46 PM
RE: A session on $_SESSION - by MGatner - 06-27-2021, 04:52 AM
RE: A session on $_SESSION - by Gary - 07-03-2021, 01:57 PM
RE: A session on $_SESSION - by InsiteFX - 07-03-2021, 09:02 PM
RE: A session on $_SESSION - by Gary - 07-06-2021, 12:26 PM
RE: A session on $_SESSION - by Gary - 07-07-2021, 04:23 AM



Theme © iAndrew 2016 - Forum software by © MyBB