[PHP-DEV] Bug #14566 Updated: Session variables become read only
ID: 14566 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.0 New Comment: The workaround to use $_SESSION['var'] is not viable right now as most places we use the global $var to access the variable and there is too much code to change this immediately. In trying to set the global $var = $_SESSION['var'] on one of the variables that has a problem, it seems that the reference is still being lost by something in PHP 4.1.1 (still tracking by what) which did not lose the reference in PHP 4.0.6. We are using a user save handler and have checked that it is saving what it receives into the database. Previous Comments: [2002-01-14 22:03:31] [EMAIL PROTECTED] BTW, my last comment works for you? To register, $_SESSION['var'] = 1234; To unregister unset($_SESSION['var']); What is your session save handler? files/mm/user/other? [2002-01-14 12:42:17] [EMAIL PROTECTED] I get the same problem on Solaris 8. Code that worked fine in PHP 4.0.6 does not work anymore with 4.1.1: - new vars are registered correctly into the session - already defined session vars cannot be modified My register_globals setting is on. [2002-01-06 22:20:20] [EMAIL PROTECTED] This comment is work around for the bug. Do not use session_register(), but use only $HTTP_SESSION_VARS or $_SESSION to register/unregister session vars. To register, $_SESSION['var'] = 1234; To unregister unset($_SESSION['var']); Then your script should work. [2001-12-18 12:55:34] [EMAIL PROTECTED] register_globals is on. I have been trying to narrow everything down to a simple test case, but have not yet been able to. It now appears that something acts differently in 4.1.0 that changes the reference of the global variable to something different than the HTTP_SESSION_VARS[] variable which did not do so in 4.0.6. A workaround is to set HTTP_SESSION_VARS[varname] = GLOBALS[varname] before the end of the script. [2001-12-17 15:55:08] [EMAIL PROTECTED] Can you post your script, and tell use the settings of register_globals? Derick The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=14566 Edit this bug report at http://bugs.php.net/?id=14566edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14566 Updated: Session variables become read only
ID: 14566 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.0 New Comment: I get the same problem on Solaris 8. Code that worked fine in PHP 4.0.6 does not work anymore with 4.1.1: - new vars are registered correctly into the session - already defined session vars cannot be modified My register_globals setting is on. Previous Comments: [2002-01-06 22:20:20] [EMAIL PROTECTED] This comment is work around for the bug. Do not use session_register(), but use only $HTTP_SESSION_VARS or $_SESSION to register/unregister session vars. To register, $_SESSION['var'] = 1234; To unregister unset($_SESSION['var']); Then your script should work. [2001-12-18 12:55:34] [EMAIL PROTECTED] register_globals is on. I have been trying to narrow everything down to a simple test case, but have not yet been able to. It now appears that something acts differently in 4.1.0 that changes the reference of the global variable to something different than the HTTP_SESSION_VARS[] variable which did not do so in 4.0.6. A workaround is to set HTTP_SESSION_VARS[varname] = GLOBALS[varname] before the end of the script. [2001-12-17 15:55:08] [EMAIL PROTECTED] Can you post your script, and tell use the settings of register_globals? Derick [2001-12-17 15:47:43] [EMAIL PROTECTED] In PHP 4.1.0 it seems that session variables can only be set once and will not be updated from subsequent pages (when using a user save_handler at least). The same code works fine in PHP 4.0.6. It seems that the write handler registered with session_set_save_handler() gets the same session data that was read with the read handler except that newly set session variables get added. Edit this bug report at http://bugs.php.net/?id=14566edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14566 Updated: Session variables become read only
ID: 14566 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.0 New Comment: BTW, my last comment works for you? To register, $_SESSION['var'] = 1234; To unregister unset($_SESSION['var']); What is your session save handler? files/mm/user/other? Previous Comments: [2002-01-14 12:42:17] [EMAIL PROTECTED] I get the same problem on Solaris 8. Code that worked fine in PHP 4.0.6 does not work anymore with 4.1.1: - new vars are registered correctly into the session - already defined session vars cannot be modified My register_globals setting is on. [2002-01-06 22:20:20] [EMAIL PROTECTED] This comment is work around for the bug. Do not use session_register(), but use only $HTTP_SESSION_VARS or $_SESSION to register/unregister session vars. To register, $_SESSION['var'] = 1234; To unregister unset($_SESSION['var']); Then your script should work. [2001-12-18 12:55:34] [EMAIL PROTECTED] register_globals is on. I have been trying to narrow everything down to a simple test case, but have not yet been able to. It now appears that something acts differently in 4.1.0 that changes the reference of the global variable to something different than the HTTP_SESSION_VARS[] variable which did not do so in 4.0.6. A workaround is to set HTTP_SESSION_VARS[varname] = GLOBALS[varname] before the end of the script. [2001-12-17 15:55:08] [EMAIL PROTECTED] Can you post your script, and tell use the settings of register_globals? Derick [2001-12-17 15:47:43] [EMAIL PROTECTED] In PHP 4.1.0 it seems that session variables can only be set once and will not be updated from subsequent pages (when using a user save_handler at least). The same code works fine in PHP 4.0.6. It seems that the write handler registered with session_set_save_handler() gets the same session data that was read with the read handler except that newly set session variables get added. Edit this bug report at http://bugs.php.net/?id=14566edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14566 Updated: Session variables become read only
ID: 14566 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.0 New Comment: This comment is work around for the bug. Do not use session_register(), but use only $HTTP_SESSION_VARS or $_SESSION to register/unregister session vars. To register, $_SESSION['var'] = 1234; To unregister unset($_SESSION['var']); Then your script should work. Previous Comments: [2001-12-18 12:55:34] [EMAIL PROTECTED] register_globals is on. I have been trying to narrow everything down to a simple test case, but have not yet been able to. It now appears that something acts differently in 4.1.0 that changes the reference of the global variable to something different than the HTTP_SESSION_VARS[] variable which did not do so in 4.0.6. A workaround is to set HTTP_SESSION_VARS[varname] = GLOBALS[varname] before the end of the script. [2001-12-17 15:55:08] [EMAIL PROTECTED] Can you post your script, and tell use the settings of register_globals? Derick [2001-12-17 15:47:43] [EMAIL PROTECTED] In PHP 4.1.0 it seems that session variables can only be set once and will not be updated from subsequent pages (when using a user save_handler at least). The same code works fine in PHP 4.0.6. It seems that the write handler registered with session_set_save_handler() gets the same session data that was read with the read handler except that newly set session variables get added. Edit this bug report at http://bugs.php.net/?id=14566edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14566 Updated: Session variables become read only
ID: 14566 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Session related Operating System: Solaris 7 PHP Version: 4.1.0 New Comment: register_globals is on. I have been trying to narrow everything down to a simple test case, but have not yet been able to. It now appears that something acts differently in 4.1.0 that changes the reference of the global variable to something different than the HTTP_SESSION_VARS[] variable which did not do so in 4.0.6. A workaround is to set HTTP_SESSION_VARS[varname] = GLOBALS[varname] before the end of the script. Previous Comments: [2001-12-17 15:55:08] [EMAIL PROTECTED] Can you post your script, and tell use the settings of register_globals? Derick [2001-12-17 15:47:43] [EMAIL PROTECTED] In PHP 4.1.0 it seems that session variables can only be set once and will not be updated from subsequent pages (when using a user save_handler at least). The same code works fine in PHP 4.0.6. It seems that the write handler registered with session_set_save_handler() gets the same session data that was read with the read handler except that newly set session variables get added. Edit this bug report at http://bugs.php.net/?id=14566edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
