Chrome is eating my session varibles (or how a Favicon saved the day)

Have had an interesting problem with the latest version of Google Chrome and a classic ASP site that I am responsible for.

The site uses session variables to control the authentication of logged in users. These are compared against a backend database to ensure that the logged in user is still authenticated while they move around the site.

I had a report from one of our external customers bemoaning the fact that we were not allowing Chrome to navigate the site, they could log in correctly and arrive on the landing page but as soon as they tried to move to any of the other authenticated pages they would be logged out.

I tried to replicate the problem on the internal test site but could not. Looking at it the differences between the two they were that the external site was secured (SSL Certificate) and being published through ISA 2006.

I created a new site (by copying the live site in IIS) and created a rule for access through the ISA server (purchasing certificate from Digicert - best certificate provider around).

AND IT WORKED. Wahoo, so the problem must be in the ISA Rule/IIS/Certificate (as these are the only things that are different).

I then spent the next day comparing the two sites (Live and Dev). Unfortunately I could find no differences at all. The rules in ISA are identical; the IIS settings are exactly the same. I rekeyed the SSL certificate so it was created from the same IIS configuration but I could not get the original site to work.

I started to look at the live site in more detail, the return code from the logout is a querystring that showed that the error was that the username or password was incorrect. I didn’t have a reason to put the site into maintenance and block customers out of the system as it was “only” Chrome users who were affected, therefore the debugging had to be done live. To do so I added a couple of lines to the ASP to show the variables:

if Request.ServerVariables("REMOTE_ADDR") = "MYEXTERNALIP" then
response.Write("." & Request.ServerVariables("REMOTE_ADDR") & "
" & session("Username") & "
" & session.SessionID)
end if

This showed that all was correct and the logouts were only happening after the next click within the site. I then had to put some error trapping into the head of the page so on the next click I could see what variables we had:

if objRS.eof = true then
objRs.Close
Set objRs = nothing
objConn.Close
Set objConn = nothing
if Request.ServerVariables("REMOTE_ADDR") = " MYEXTERNALIP " then
response.Redirect("/debugpage.asp")
else
response.Redirect("/index.asp?Error=2")
end if
end if

My debugpage.asp had the following in it:
response.Write("." & Request.ServerVariables("REMOTE_ADDR") & "
" & session("Username") & "
" & session.SessionID)


Strangely the output on this had:
IPAddress
blankline
SessionID

So something was eating the session("Username") variable…..

Looking through the code there didn’t seem to be anything that would be removing the variable, I stepped through the code line by line on paper and could not see anything that would be removing the variable, the only sessions.abandon was in the logout, index landing page and the global.asa PLUS the other session variables were not getting cleared either (and this was getting away from the fact it was ONLY happening on Chrome).

I next fired up a test laptop and downloaded a copy of fiddler2. I put it onto a test laptop as I needed to decrypt and inspect HTTPS sessions, to do this in Fiddler2 you have to add a certificate to the local store and its recommended that you only ever install the HTTPS monitoring on a test machine.

Once I started to look at the output I saw the following:


This showed that there was a 302 response when trying to get to favicon.ico (line 91)……. Hummm, I don’t have a favicon so why was it redirecting?

AND HANG ON, what’s that on line 93? Why is the Secure URL turning up when I’m browsing the Dev site…… Suddenly a light bulb went off in my head. Scroll back to how I created the Dev site (hint ….. the IIS settings are exactly the same……).

The Dev site was a copy of the secure files, that includes the Web.config. Web.config contains the error page redirections:


So what was happening then?
  1. Customer enters Dev site
  2. Chrome (for some reason) demands favicon file
  3. IIS can’t find favicon so issues a 302 redirect to a 404 page
  4. Cusomised ASP page which includes the following code: session("Username ") = ""
  5. As customer is on Dev site the session variable is NOT cleared (it’s the wrong domain) But if the user is on the Secure site then the code will execute correctly and clear the variable.

So, what the hell does this all mean?
For some reason the latest version of Chrome insists on trying to download favicon.ico, as this doesn’t exist a 404 is generated on the server and *if* you have some code to trap 404’s then it will execute.

The lesson:
When copying websites carefully look at your web.config and put a favicon.ico on the root of your websites so that Chrome doesn’t put a whole load of 404’s into your weblogs (or worse stops the customers from using your site).

Global Address List not up to date

First Check Outlook Web Access as this will always be up to date. If the staff members are missing from OWA then this is a different problem.



If the staff members are in OWA try a manual download

Outlook > Tools > Send/Receive > Download Address Book

Uncheck Download changes since last Send/Receive > OK



If this fails then repair the Outlook Profile:

Outlook > Account Settings > repair > Next

If the wizard reports that Outlook need to be restarted then restart Outlook and retry the manual download above



If the manual download fails start Services.msc (elevated/run as end user is logged in)

Check that:



* Automatic Updates

* Background Intelligent transfer Service



are both set to Automatic and are started.

If not, make those changes.



Return to Outlook and try the manual download again.