From: Paul L. <pa...@sq...> - 2007-10-23 19:10:13
|
<snip> > I was putting together a new 1.4.11 install in on our staging site to > replace the 1.4.10a install on our production site. > > Everything went well until I enabled the sessiondb.php preload, and then > login.php died. Zero output, zero logging. > > Tracked it to this change > > --- login.php.10 Tue Oct 23 01:23:22 2007 > +++ login.php.11 Tue Oct 23 01:23:45 2007 > @@ -44,18 +44,29 @@ > * In case the last session was not terminated properly, make sure > * we get a new one, but make sure we preserve session_expired_* > */ > +$sep = ''; > +$sel = ''; > +sqGetGlobalVar('session_expired_post', $sep, SQ_SESSION); > +sqGetGlobalVar('session_expired_location', $sel, SQ_SESSION); > > -if ( !empty($_SESSION['session_expired_post']) && !empty($_SESSION['session_expired_location']) ) { > - $sep = $_SESSION['session_expired_post']; > - $sel = $_SESSION['session_expired_location']; > +/* blow away session */ > +sqsession_destroy(); > > - sqsession_destroy(); > +/** > + * in some rare instances, the session seems to stick > + * around even after destroying it (!!), so if it does, > + * we'll manually flatten the $_SESSION data > + */ > +if (!empty($_SESSION)) { > + $_SESSION = array(); > +} > > - sqsession_is_active(); > - sqsession_register($sep, 'session_expired_post'); > +/* put session_expired_* variables back in session */ > +sqsession_is_active(); > +if (!empty($sel)) { > sqsession_register($sel, 'session_expired_location'); > -} else { > - sqsession_destroy(); > + if (!empty($sep)) > + sqsession_register($sep, 'session_expired_post'); > } > > > The problem is sqsession_destroy(). Not only does it destroy the session, > it blows away session_set_save_handler. The following call to sqsession_is_active() is > a passthrough to session_start(). In this case, session_module_name is still 'user' > but the save handler has been blown away. Execution stops without any logs or > displayed errors when session_start() is called. Sounds like a PHP bug to me. I see no rationale why destroying a session should affect the session handler. Have you asked around the PHP world? > As it turns out, this was a problem before, but *only* when > > if ( !empty($_SESSION['session_expired_post']) && !empty($_SESSION['session_expired_location']) ) > > kicked in. The change to login.php in 1.4.11 made it a 100% hit. > > > The workaround for me is to edit login.php to call > > session_set_save_handler('sess_open','sess_close','sess_read','sess_write','sess_destroy','sess_gc'); > > after sqsession_destroy() but before sqsession_is_active() > > > I did a quick review and didn't find any other places where a > start can follow a destroy within the same run, but it is something to be aware of. > > > Would a new hook be in order? One that would run right after the require_once > init section at the start of every script and in between and destroy and start? I can see no use for such a hook beside to alleviate this PHP anomaly. > It would may it easy to declare a customer session handler in a plugin and have it > set/reset to use without the preload trick. |