It was a compromise to keep code complexity down. In order to tag every request from IE...we have to have hooks in place at many more places (not to mention supporting the different things IE6, 7 and 8 do). So, as a compromise we decided to keep it down to only the single hook that allows us to tag top level requests.
This fix on our side was to just strip the chromeframe identifier from the user agent string, although it makes me wonder what other browser extensions cause similar issues and whether invalidating a session when the user agent changes is even a worthwhile security measure.
Hi Brad, we've run into the same issue. Like you we also invalidate sessions when the user agent changes and this behavior from Chrome Frame seems to be causing problems for our users too. We'll probably have to do what you did as well -- strip the chromeframe part off the user agent string before comparing it.
ReplyDeleteWe've also run into a similar problem with IE8 -- it can change it's behavior mid-session and switch over into "IE7 compatibility mode". When it does that, the UA string switches to MSIE/7.x from MSIE/8.x. As we'll do with the chromeframe issue, our solution was to modify the user agent string before doing the check -- masking out the version number in IE user agent strings to end up with MSIE/#.# no matter whether it is 7 or 8.
Like you I wonder if this security measure is even worth doing still.
---Lawrence