Matching the User-Agent in the Session Class

[eluser]caleblloyd[/eluser]
I have been developing using Codeigniter for a few years now, and seem to always have a problem with getting locked out of a session after navigating a few pages on a website in certain versions of Internet Explorer. I have narrowed this down to the "sess_match_useragent" in the Session Class.

The problem does not come from Codeigniter; the "sess_match_useragent" functionality works exactly as it should. The problem is that some versions of Internet Explorer on certain Operating Systems will report different user-agents from one page to the next.

For instance, I am using Internet Explorer 8 on Windows XP SP3. I am printing $_SERVER['HTTP_USER_AGENT'] to the screen, because that is where Codeigniter 2.02 appears to get its User-Agent information from. One page load reads:

Code:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; etc...

And on a subsequent page load to the same domain in the same browser it will read:

Code:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; etc...

I believe that this is an Internet Explorer problem and not a Codeigniter problem, however the default functionality of the Session Class to match the User-Agent causes problems when this bug occurs in IE. Which brings me to my next question- Why is codeigniter's default behavior to set "sess_match_useragent" to TRUE in the Session Preferences?


I understand that one reason could be for security purposes- so that a cookie that is read over an unsecured network cannot be recreated in a different browser in order to "steal a user's session". While this is true, most people that are capable of understanding how to steal a cookie over an unsecured connection are also capable of spoofing the user-agent quite easily, so I do not think this is a strong enough argument to call for always matching the user-agent.


Is there any other reason that matching the user-agent is defaulted to TRUE? I know that this IE bug effects many users of sites that run on Codeigniter, and would like to discuss the adverse effects of changing its default value to FALSE.

[eluser]InsiteFX[/eluser]
You do know that the user_agent field in the session table has been changed!

New session table:

Code:

-- --------------------------------------------------------------

--
-- Table structure for CodeIgniter ci_sessions.
--
DROP TABLE IF EXISTS `ci_sessions`;

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

-- -------------------------------------------------------------
--  `user_data` text,       COMMENT - maximum length of 65535 characters.
--  `user_data` mediumtext, COMMENT - maximum length of 16777215 characters.
--  `user_data` longtext,   COMMENT - maximum length of 4294967295 characters.

InsiteFX

[eluser]caleblloyd[/eluser]
Regardless, the IE bug reports different user-agents on subsequent page loads, which I got by printing $_SERVER[‘HTTP_USER_AGENT’], a PHP Variable outside of Codeigniter. So I've already nailed down that this is an IE Bug, not a Codeigniter bug. The only way to code around this is to disable “sess_match_useragent”, and I am wondering why it is not just set to FALSE to begin with.

[eluser]InsiteFX[/eluser]
All Browsers return multiple user agent strings! In the case of IE every IE browser that Microsoft has made uses the sub string MSIE.

Here if you want to code for every version of IE!
User Agent String.Com

InsiteFX

[eluser]caleblloyd[/eluser]
The bug that I'm experiencing is that the SAME IE 8 browser sends two different user-agents on two subsequent page loads. So you go to my CI site, login, and it registers the session under the first user-agent. Next, you click a link and the SAME browser sends a different user-agent in its header (see my original post). This causes the original session to fail matching to the second user-agent and the user is kicked off the authenticated portion of the site after clicking the link. This entire process occurred within the same IE8 browser, which should have sent the same user-agent on both pages but didn't.

I can only recreate this bug in IE 8, and specifically on an XP SP3 machine so it is likely the minor version of IE 8 on this computer. But other users of my website have had this problem in IE before, which brings me back to my original question:

Why is codeigniter’s default behavior to set “sess_match_useragent” to TRUE in the Session Preferences?

[eluser]WanWizard[/eluser]
Because it's a security feature, and nobody has ever seen a browser that alters it's UA string before?

p.s. I think this is something than needs further examination, because I can't believe that IE8 calls itself IE7 on the next page request. Do you have some funny emulation mode activated? Is your HTML bad so that IE falls back to IE7 mode?

[eluser]osci[/eluser]
In MSDN
msdn.microsoft.com/en-us/library/dd371735(v=vs.85).aspx

(url has brackets and got stripped so copy link)

Description

The User Agent String is the Internet Explorer identifier that provides data about its version and other attributes to web servers. Many web applications rely on, and piggyback on, the IE User Agent String. Those that do so and depend on an earlier version number will be impacted. The User Agent string now includes the string 'Trident/4.0' in order to allow differentiation between the Internet Explorer 7 User Agent String and the Internet Explorer 8 User Agent string when running in Internet Explorer 7 Compatibility View. See Understanding User Agent Strings for details.

Also in agent strings

Version token Description
MSIE 9.0 Internet Explorer 9
MSIE 8.0 Internet Explorer 8 or IE8 Compatibility View/Browser Mode
MSIE 7.0 Internet Explorer 7 or IE7 Compatibility View/Browser Mode
MSIE 6.0 Microsoft Internet Explorer 6

And

Token Description
Trident/5.0 Internet Explorer 9
Trident/4.0 Internet Explorer 8

And I read that IE10 will have Trident/6.0 (somewhere in ie10 developer platform site)

Which means that when ie8 is in compatibility view it returns ie7 but to always distinguish you should check for 'Trident/4.0' for IE8 regardless mode.

[eluser]Hoopoe[/eluser]
so changing sess_match_useragent to FALSE will solve it ?

Hoopoe

[eluser]osci[/eluser]
No, I don't think that's your preferred solution.
Maybe as wanwizard stated

Is your HTML bad so that IE falls back to IE7 mode?

or

Do you have some funny emulation mode activated?

Unless ie8 reports as ie8, gets the page, goes into compatibility and reports back as ie7.
Could it be that the one machine you have problem is the only one with compatibility mode on?

And if that's the case, wow, ie does the trick again
Why would we need a browser compatibility view anyway???? (guess, ie developers suck).

[eluser]newsmuncher[/eluser]
You didn't happen to jump between IE8 and compatibility mode did you?