Bug #63379 [Com]: Warning when using session_regenerate_id(TRUE) with a SessionHandler
Edit report at https://bugs.php.net/bug.php?id=63379&edit=1
ID: 63379
Comment by: beatdrdre at hotmail dot com
Reported by: avatar2004-php at yahoo dot fr
Summary: Warning when using session_regenerate_id(TRUE) with
a SessionHandler
Status: Assigned
Type: Bug
Package: Session related
Operating System: Gentoo
PHP Version: 5.4.8
Assigned To: arpad
Block user comment: N
Private report: N
New Comment:
Whereever we go,we always hope to get perfect things.<a href="http://www.cheap-beats-by-dre-sale-outlet.com/"><strong>beats
by dre sale</strong></a> is such a place that offer me good items.<a href="http://www.cheap-beats-by-dre-sale-outlet.com/"><strong>wholesale
beats by dre</strong></a> is quite good with the service.I like the <a href="http://www.cheap-beats-by-dre-sale-outlet.com/"><strong>beats
by dre outlet</strong></a>.So I want you can love it too.
Previous Comments:
------------------------------------------------------------------------
[2012-10-29 04:21:47] avatar2004-php at yahoo dot fr
Looking at the code, it feels like the very semantics of the mod_user_is_open flag are not exactly
consistent.
The flag is a global, yet it is manipulated by instance code. Meaning if the user space code uses
several handlers interchangeably, the result can quickly become confusing.
I suggest a decision should be made as to whether the SessionHandler is a stateless, thin wrapper
for the handler calls in which case it should default to the same checks as the procedural API.
Otherwise, the flag should really be an instance variable used to track the proper invocation
sequence of the different callbacks and make sure THIS handler is open before calling dependent
routines.
Adding an instance variable to the (base) class though is probably not worth it. The session
management semantics are already defined by the procedural API which uses a global session state
flag (session_status). If required for a handler implementation, the flag can simply be implemented
in user space.
Just my 2c.
------------------------------------------------------------------------
[2012-10-29 03:07:41] laruence@php.net
I mean, maybe only reset it in close handler?
------------------------------------------------------------------------
[2012-10-29 03:07:08] laruence@php.net
is the reseting of user_is_open necessary?
diff --git a/ext/session/mod_user_class.c b/ext/session/mod_user_class.c
index 70d2f40..4edac28 100644
--- a/ext/session/mod_user_class.c
+++ b/ext/session/mod_user_class.c
@@ -121,7 +121,6 @@ PHP_METHOD(SessionHandler, destroy)
return;
}
- PS(mod_user_is_open) = 0;
RETVAL_BOOL(SUCCESS == PS(default_mod)->s_destroy(&PS(mod_data), key
TSRMLS_CC));
}
/* }}} */
------------------------------------------------------------------------
[2012-10-29 01:14:11] avatar2004-php at yahoo dot fr
If I understand correctly and "mod_user_is_open" is just a global state parameter used by
the SessionHandler instance, I was wondering why the check wasn't being done on
"session_status" instead to conform with the rest of the session_* API ?
------------------------------------------------------------------------
[2012-10-29 01:04:34] avatar2004-php at yahoo dot fr
Description:
------------
It seems there's an issue with the SessionHandler implementation and
the way the destroy handler is invoked when using
session_regenerate_id(TRUE)
The problem seems to come from using the global "mod_user_is_open" in
the PS_SANITY_CHECK_IS_OPEN macro (in ext/session/mod_user_class.c).
The test script generates an undue warning:
Test script:
---------------
$handler = new SessionHandler();
session_set_save_handler($handler, TRUE); // or FALSE, doesn't matter
session_start();
session_regenerate_id(TRUE);
//session_write_close();
Expected result:
----------------
No warning
Actual result:
--------------
PHP Warning: Unknown: Parent session handler is not open in Unknown on line 0
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=63379&edit=1
Thread (9 messages)