Session Failures |
[eluser]Ian Cook[/eluser]
Under what circumstances could a session appear to mysteriously expire, or in some other way fail to reload between page views? I have this intermittent problem where, between page views, the user session will get dropped. Before I implemented auth checking code, the page would load but anything requiring data from the session would fail to load that data. After I implemented auth checking, it would just kick the user back to the login page ( as would be expected due to missing or expired session data ). I've tested 5 minute and 10 minute time spans to see if the timeout is occurring too early, but neither of those times cause the issue to happen. And in any case, I've seen the session drop after only a few seconds. I've clicked between every page of the site ( there are only 6 pages ) to see if it was a certain page causing it to drop. No dice. Sessions work perfectly, other than this intermittent and unreproducible error. I'm encrypting the session cookie. I'm storing userdata in a database table. The session is set to expire after 7200 seconds. I'm setting the cookie for my domain properly. Here is my session config from config/config.php Code: /* I'm mostly trying to find out under what scenarios a session COULD fail.
[eluser]tomcode[/eluser]
Hi thinkspill, Have You tried without use of database ? I'd try that to reduce possible error sources. Have You tried without session encryption ? I've had once the case where a server would not accept encrypted sessions, while uncrypted did pass. I got error messages, though, which leads me to : Have You error messages enabled ? Edit : Have You tried without user agent matching ?
[eluser]Ian Cook[/eluser]
I have not tried without database session userdata storage, or encryption, or user-agent matching. I'll give it a shot. I do have error messages enabled (E_ALL), but there are no errors.
[eluser]Popcorn[/eluser]
What browser are you using? Try removing the underscore from the cookie name.
[eluser]Ian Cook[/eluser]
Oooookay, I've got a little more concrete information now. So it appears that when the session ID regeneration occurs, the userdata that is stored in the database table is dumped into the cookie. If this userdata is greater than 4k, the cookie no longer works ( as expected, cookies cant handle that much data ). I tested this by doing the following... First I changed the session id regen time to 20 seconds, for faster testing. Then I set an additional cookie that just contained the session id. On each page load I'd compare that session id to the real session id to determine if it had changed. If it has changed, its either because the sessiond id has been regenerated or the session has been lost entirely. So I check if my "is auth'd" variable is still present. If so, then I'll update the session id cookie copy with the new one and continue on. If the "is auth'd" variable is not set, and the session id copy does not match the real curent session id, the session has been lost. I filled the session userdata up with a ton of junk data. If the userdata totals less than ~4k when the session regen occurs, the session remains intact. If the userdata totals more than ~4k, the session dies after the regen occurs. So, in summary, the session library seems to be putting a copy of all the userdata into the cookie when it regenerates the session id. This is a bug, right?
[eluser]newsun[/eluser]
Ok, So the problem here is with the Session.php library currently in SVN. There was a change which made where the userdata saves to the db and the identifying data saves to the cookie as well as the db, if saving to a db was setup and enabled. The issue thinkspill was having was on the regeneration of the session id the userdata was getting put into the cookie, instead of the db. Below is the function with the problem. I broke each change out into code snippets: Code: function sess_update() Code: #Set the cookie data to default Code: // Update the session ID and last_activity field in the DB if needed Code: #Sets cookie data to omit the custom userdata Code: $this->CI->db->query($this->CI->db->update_string($this->sess_table_name, array('last_activity' => $this->now, 'session_id' => $new_sessid), array('session_id' => $old_sessid))); Also, there was some optimizing that I did to the sess_write() function as well, eliminating a redundant loop: Code: function sess_write() Code: $custom_userdata = $this->userdata; Code: # assigning the cookie data here as well so it does not have to be removed as previous code Code: foreach (array('session_id','ip_address','user_agent','last_activity') as $val) Code: $cookie_userdata[$val] = $this->userdata[$val]; Code: unset($custom_userdata[$val]); Code: /*foreach (array_keys($custom_userdata) as $val) #removed as this can be accomplished earlier with less code Code: // Serialize the custom data array so we can store it I have attached a copy of this file with .txt appended, I think these changes should be incorporated into the copy in SVN, I just don't have access otherwise I would do it.
[eluser]newsun[/eluser]
I was hoping someone who has svn access would have read the last part about fixing the Session.php file. Or maybe give me a direction on where to post or how to get access to commit a change.
[eluser]tomcode[/eluser]
If You'll have no answer from one of the CI crew (not sure there working the weekend) I suggest You to repost with specifying the svn version in the title. You can also go to the Bug tracker. Chances are that You'll find it there already.
[eluser]Derek Jones[/eluser]
Hi newsun, I don't see the file attachment. Do you mind zipping your Session.php file and attaching it here? I'll be happy to take a look at it.
[eluser]newsun[/eluser]
Hmm, yeah looks like my original attachment did not hold. He is another attempt to attach Session.php as Session.zip compressed file. |
Welcome Guest, Not a member yet? Register Sign In |