Description: ------------ MDB2.php: 220 tests whether there are results of a given query (i.e. a session does exist) *with no range*. This `if` is false, and the `else` gets invoked. MDB2.php: 231 is supposed to update the existing session data, but it *does* have a range test, so the session data never gets updated. ------- $query = "UPDATE %s SET expiry = %d, data = %s"; $query .= " WHERE id = %s AND expiry >= %d"; -------- In my case, session expiry time is set quite low. When my session expires I would expect this specific entry in the database to get updated with new session information as my session_id never* changes. This is n't currently happening as the above two lines pasted from MDB2.php prevent newer session information from being written. This means one of two things. Either a) I should be getting a new session id upon expiration which I'm not, or be this code (above) is broken. Attached you'll find a patch which works for me (TM). Test script: --------------- I do not have a test case readily available. Expected result: ---------------- Upon expiration of a session, I would expect that a new session would be created and I would be brought back to a login screen where the session data could be rebuilt depending on user input natually. Additiona lly, I would expect when I submit data (username/password for example) from this screen the variables I set would in fact be set in the current session, but this doesn't happen as the check to update said sessio n never succeeds as pointed out in the patch which again works (TM). Actual result: -------------- Unable to re-establish session. Once expired, browser MUST be restarted.

The following patch has been added/updated: Patch Name: MDB2.php.patch Revision: 1250651412 URL: http://pear.php.net/bugs/patch-display.php?bug=16538&patch=MDB2.php.patch&revision=1250651412&display=1

I must admit, with this patch the following never evaluates to true: if(HTTP_Session2::isExpired() || HTTP_Session2::isIdle()){ So there may be more to it. Having the ability to log in is far superior than not being able to log back into the system however.

I don't understand. It's only supposed to update the session if it's still valid, defined by an expiration time. That's why that is in there. When a session expires, you do not want the same session id. You want a new one.

This is strange then. I've never given a new session id as the updates to the session AFTER it enpires are still happening on the original id. I'll do more debugging tonight and try to figure out what is going on.

Technically, if you use a file handler (e.g. standard php), it would clean those up (= garbage collect (gc)) after a while using the session.gc_* variables. Let me know what you dig up tomorrow.

Before debugging tonight, I must admit I'm using the wrong terminology. The session hasn't expired, but has become idle. If there is any confusion caused by this, I apologies. (I knew what I meant, just stated it wrong) What I've stated still applies however; given an idle session, the original sessions data isn't recoverable from the HTTP_Session2::start method as the session data previously set isn't available when a session becomes idle. Whether or not this has something to do with the code in the MDB2 container code I'm not completely sure. Like I mentioned I will debug this fully tonight and hopefully provide a useful test case so that it can be repeated.

Ok, I have made a little headway concerning this problem. This is partially a documentation problem and partially an example problem (or I suppose a coding problem provided the example I'm about to share is correct). On the following page: http://pear.php.net/manual/en/package.http.http-session2.intro.php There are two examples of setting the idle and expiration time. They are: HTTP_Session2::setExpire(time() + 60 * 60); // expires in one hour HTTP_Session2::setIdle(time() + 10 * 60); // idles in ten minutes These examples are wrong because the method isIdle checks that __HTTP_Session2_Idle_TS + __HTTP_Session2_Idle <= time(); The same holds true for the isExpired method. The correct example for setting a 10 minute idle session should be: HTTP_Session2::setIdle(10 * 60); I'm going to chalk this one up to the documentation provided on Session2 being out of date, making the appropriate changes to my application and see if I still experience any weird problems.

Ok, so even with the changes I made, I'm still left in a precarious state upon becoming expired. Given the following session table: ---------------------------------------------------------------- yoyo=> select id, expiry from sessiondata; id | expiry ----------------------------------+------------ 61513d0bd86eb471b35fb2900f8545db | 1250754062 (1 row) ---------------------------------------------------------------- HTTP_Session2::start(); runs the following sql command and returns 0 results: ---------------------------------------------------------------- yoyo=> SELECT data FROM sessiondata WHERE id = '61513d0bd86eb471b35fb2900f8545db' AND expiry >= 1250832310; data ------ (0 rows) ---------------------------------------------------------------- The above implies my session has expired and I would be given a new session maybe even with a new session id, but that doesn't happen HTTP_Session2::isExpired() checks variables that don't exist and always return false so none of the HTTP_Session2::destroy(); code (that I have) ever gets executed. My program happily goes on assuming I haven't expired. Again, my id hasn't changed, so I'm SOL. Being that I don't have session data yet, I go back to my login screen, enter my credentials and the following query is then executed on the server (edited taking o ut unless information): ------------------------------------------------------------------ yoyo=> UPDATE sessiondata SET expiry = 1250833332, data = '__HTTP_Session2_Info|i:1;__HTTP_Session2_Expire|i:50400;__HTTP_Session2_Expire_TS|i:1250831892;__HTTP_Ses sion2_Idle|i:900;__HTTP_Session2_Idle_TS|i:1250831892' UPDATE 0 ------------------------------------------------------------------ This obviously fails to set any session data as well as I'm still in this expired state (or is a new state with the same session id?) and can't get out of it. - What I believe is happening is that the method start(), calls detectID(), which in turns sees my cookie that was first set. - Then if left alone the session expires. - When it expires, the sql commands issued as shown above never make that session recoverable short of restarting the browser to obtain a completely new id. a) This is because updates check for a newer expiry when updating "AND expiry >= 1250831892" which is never true. Hope this helps.

Per my last comment the update statement is actually: UPDATE sessiondata SET expiry = 1250833332, data = '__HTTP_Session2_Info|i:1;__HTTP_Session2_Expire|i:50400;__HTTP_Session2_Expire_TS|i:1250831892;__HTTP_Session2_I dle|i:900;__HTTP_Session2_Idle_TS|i:1250831892;;' WHERE id = '61513d0bd86eb471b35fb2900f8545db' AND expiry >= 1250831892

The following patch has been added/updated: Patch Name: MDB2-2.php.patch Revision: 1250888223 URL: http://pear.php.net/bugs/patch-display.php?bug=16538&patch=MDB2-2.php.patch&revision=1250888223&display=1

I've added the above patch. Essentially, I've changed the read method to always select a record from the database provided it exists regardless if it expired or not. This allows the isExpired method to work properly and kill the session. Thoughts on this?

Yeah, regardless -- if expired, you should use a new session id and not "re-activate" an expired one.