Description: ------------ The setExpire() property only works if you call it before the isExpired() property. This is not recommended as many users, who I am one of, will want to use it the other way round. Test script: --------------- <?php // This code is called at the beginning of each web page: if ( HTTP_Session2::isExpired() ) { HTTP_Session2::destroy(); header('Location: login.php?ShowExpiredMessage'); } ?> //login.php <?php if ( isset($_POST['login']) ) { //... login validation if ( $loginIsSuccess ) { HTTP_Session2::setExpire(24*3600); // Expire in 24 hours } } Expected result: ---------------- This code will destroy the session after 24 hours and make the user re-login. It's a small example but should be sufficient to explain what I mean. I also changed the documentation of how to use: HTTP_Session2::setExpire(time() + 60 * 60); Should be: HTTP_Session2::setExpire(60 * 60); Actual result: -------------- It does not work if you call the setExpire() property after isExpired(), to solve this SESSION variables must be used. The patch contains the solutions.

I also updated the setIdle(), sessionValidThru(), isIdle() and updateIdle() properties.

First of all, why is it not recommended? Also, can you create a "real" patch and upload that instead? That would help a lot. I'll discuss your changes with my co-developer as soon as I can. Thanks for the report.

In my situation, my config.php file contains: <?php // Max lifetime of a session $_SETTINGS['session_expire'] = 24 * 3600; // 24 hours //-- // If the session is expired log out otherwise reset the expiration time //-- if ( HTTP_Session2::isExpired() ) { if ( isset($_SESSION['uID']) || isset($_SESSION['pwd_id']) ) { HTTP_Session2::clear(); header('Location: login.php?SessionExpired'); exit; } } ?> My config.php file contains the custom settings which every page needs, it also contains my database connection details. So in my login.php script, I set an expiration time when the user logs in. Remember that config.php is called at the beginning of my login.php file. <?php if ( isset($validationWentSuccessful) ) { HTTP_Session2::setExpire($_SETTINGS['session_expire']); //Set session variables, etc. } ?> How the setExpire() property currently works it is not possible for me to use this property this way, I would have to call the setExpire() property before the isExpired() property as the variable expiration variable in the HTTP_Session2 is $GLOBALS['__HTTP_Session2_Expire'] and is not being remembered. If you use it as $_SESSION['__HTTP_Session2_Expire'] it would be remember and users would have many more ways to use these properties. If I go back to my situation I would have to add more code in every file in order to get it work the way I like, using the $GLOBALS['__HTTP_Session2_Expire'] as $_SESSION['__HTTP_Session2_Expire'] would save me more time. I'm also sorry about the patch, it contains the "fixes" but I had to remove the rest of the code as the max upload filesize was 10KB, the full file was 20KB+.

Create a patch using the "diff" command, please. That should *only* get us your changes. :) In general this seems to be a use-probem. ;-) Point taken the docs are not complete and completely error-free (working on it :-)), but here is what I think: The $GLOBALS code is actually just used during the runtime of the script to "set" necessary values. The values from $GLOBALS are not used to really extend anything, it's an initial "set" used to a) tell the code in general for how long requests are valid and b) to check if a session has expired (the data to dertime all this is saved in the database or filesystem, which is why it's not necessary to prolong it. If you want your session to last for 24 hours, you should probably look into HTTP_Session2::useCookies() and session_set_cookie_params(): <http://cvs.php.net/viewvc.cgi/pear/HTTP_Session2/HTTP/Session2.php?revision=1.15&view=markup> At least this works for me pretty well. Using useCookies() I create a cookie in the browser to store my session ID. session_set_cookie_params (which should be wrapped in HTTP_Session2 code (it's on my todo)) controls how long this cookie is stored on the client-side. By default the cookie is delete when the user closes his browser. So when people come back to your site, the cookie is still "set" and based on this cookie (and the session ID stored in it), HTTP_Session2 finds the session and then determines if the variables saved are still valid, or expired, etc..

I noticed that what I needed was the ini_set('session.gc_maxlifetime', 86400); setting and not make use of the setExpire() property, the "session.gc_maxlifetime" also caused the infinite loop from my other issue. If the setExpire() property contains a higher value than the 'session.gc_maxlifetime' setting this will not have any effect and in my case it caused problems. Perhaps you should mention this in the description of the property to prevent users from making the same mistake as I did? Anyways, thank you for your help and keep up the good work! Regards, Isaak

Will put this on my list. Thanks! :)

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Your expire problem should be fixed in CVS too. Didn't understand what you were getting on earlier.