I've been using CI v1.73 for ages and recently decided that a new, internal project should be written with CI v3.0. That experiment fell apart when I ran afoul of the Session library and its transition to native PHP sessions. So I'm a little sensitive to Session issues, at the moment.
I've dialed back a notch to CI v2.2.2, rather than beat my head against a wall with v3.0.
It appears that the Session library in v2.2.2 has issues, too - or at least when I've used it.
Under CI1.7x, the session cookie prototype was
PHP Code:
'session_id' => md5(uniqid($sessid, TRUE)),
'ip_address' => $this->CI->input->ip_address(),
'user_agent' => substr($this->CI->input->user_agent(), 0, 120),
'last_activity' => $this->now
When new user data was entered, it would be serialized at the same level as
session_id,
ip_address,
user_agent and
last_activity.
Under CIv2.2.2, the session cookie prototype seems to be
PHP Code:
'session_id' => md5(uniqid($sessid, TRUE)),
'ip_address' => $this->CI->input->ip_address(),
'user_agent' => substr($this->CI->input->user_agent(), 0, 120),
'last_activity' => $this->now,
'user_data' => ''
Where new user data seems destined to reside within the
user_data as a serialized array, instead of as separate variable, themselves.
While playing with it today, it seems like any time I call
set_userdata, the cookie gets written out, it writes the cookie without the base data (
session_id,
ip_address,
user_agent and
last_activity).
In this case, when the next class instantiation tries to confirm that the session cookie has the correct format, it doesn't find the base variables, assumes it's a mal-formed cookie, then rebuilds a default cookies from the prototype, and returns the new prototype version to my calling code, instead of the actual contents.
The few instances where I've seen the cookie with userdata in it, it was not within the
user_data container.
Am I imagining this, or is the CI v2.2.2 session library broken?
