Session in IE 7 being stored in DB as Mozilla

[eluser]GeXus[/eluser]
I'm using CI Reactor 2.0.2

- Session library auto loaded

Config:

Code:

$config['sess_cookie_name']    = 'fifteensite';
$config['sess_expiration']        = 7200;
$config['sess_expire_on_close']    = FALSE;
$config['sess_encrypt_cookie']    = FALSE;
$config['sess_use_database']    = TRUE;
$config['sess_table_name']    = 'sessions';
$config['sess_match_ip']    = FALSE;
$config['sess_match_useragent']    = TRUE;
$config['sess_time_to_update']    = 300;

DB:

Code:

CREATE TABLE IF NOT EXISTS `sessions` (
  `session_id` varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '0',
  `ip_address` varchar(16) COLLATE utf8_bin NOT NULL DEFAULT '0',
  `user_agent` varchar(200) COLLATE utf8_bin NOT NULL,
  `last_activity` int(10) unsigned NOT NULL DEFAULT '0',
  `user_data` text COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`session_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

When using IE 8, sessions are not being stored. As soon as I refresh or navigate away from a page that set a session, the session is gone. The same happens when not using the DB.

Any help would be great, I've had this issue in the past but it was due to the underscore in the cookie name, but that's not the case now.

[eluser]GeXus[/eluser]
Ok, I changed 'sess_match_useragent' to false. It works.

[eluser]WanWizard[/eluser]
I've seen reports of people claiming that IE8 sends different UA strings, but I haven't been able to verify that.

As a test, could you add this to your code (for example in the constructor of a controller), activate logging, load a few pages, and post the resulting lines here?

Code:

log_message('info', 'IE8: '.$_SERVER["HTTP_USER_AGENT"]);

I'm very curious to see what causes this...

[eluser]GeXus[/eluser]

INFO - 2011-06-08 15:38:32 --> IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; HPDTDF; .NET4.0C; BRI/2; AskTbFWV5/5.11.3.15590)

INFO - 2011-06-08 15:38:32 --> IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; HPDTDF; .NET4.0C; BRI/2; AskTbFWV5/5.11.3.15590)


INFO - 2011-06-08 15:38:34 --> IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; HPDTDF; .NET4.0C; BRI/2; AskTbFWV5/5.11.3.15590)


INFO - 2011-06-08 15:38:35 --> IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; HPDTDF; .NET4.0C; BRI/2; AskTbFWV5/5.11.3.15590)

These three records are from going to the page and refreshing 3 times. I navigated away from the page, then came back to it, several times, but no logs were written for those.

However, I then refreshed again and the log was written.

INFO - 2011-06-08 15:42:36 --> IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; HPDTDF; .NET4.0C; BRI/2; AskTbFWV5/5.11.3.15590)

[eluser]WanWizard[/eluser]
They look very identical to me, if I'm not mistaken.

So disabling the UA match isn't the solution, it's masking some other error.

This is quite a long UA string. 213 characters according to my count. Which exceeds the definition of your session table column (VARCHAR 200). So the value gets truncated when it's stored in the database, and causes a mismatch when the session is read back and verified.

Defining the column as TEXT instead of VARCHAR(200) would solve your problem. As this is basically a bug in the Session library, I think you should report this: http://bitbucket.org/ellislab/codeigniter/issues or amend https://bitbucket.org/ellislab/codeignit...ase-cookie which is a related issue.

[eluser]InsiteFX[/eluser]
@WanWizard,

If you check the Session Class they are only checking for the first 120 characters of the user agent string! So I would report this as a BUG!

InsiteFX

[eluser]WanWizard[/eluser]
I that case I'm not so sure. Since the docs state (as per your post in the other thread) that the field should be defined as VARCHAR(120), that check would then actually work.

But I find it a rediculous solution. The field should be large enough to store the entire UA string, so the entire string could be checked for a match, and no tricks are needed.

Besides that, I know MySQL truncates the value when the field isn't big enough, but I'm not so sure about other RDBMS's.