InternetGetCookie/InternetSetCookie (WinInet) changed with Internet Explorer 7
So last week I was implementing the Google Authentication for Installed Applications in Feed Vortex and after I solved the cross-thread GUI access problems I ran into a new batch of problems. You see, Google authenticates using cookies, but when you use the Google Authentication API for desktop applications you only get the value that needs to be stored in the cookie and not the cookie itself. Since I P/Invoke the WinInet functions, I needed to store the cookie using the InternetSetCookie API and then the WinInet APIs themselves will figure out what cookie to get.
But it wasn’t so simple. Using Fire Fox I noticed that Google stores its cookies with the domain “.google.com” and the path “/”. But when I try to do that I get error 12006 (ERROR_INTERNET_UNRECOGNIZED_SCHEME). Allright, so I add “http://” to the front, but then I confronted with error 123 (ERROR_INVALID_NAME). This confused me. But then I remembered I was running IE7 Beta 3 on my desktop, so I put the code on my laptop which still uses goold old IE6 and it works.
One of the changes for IE7 is their more secure URL cracking methods. But apparently IE7 also updates the WinInet.dll, which other applications use. So it’s new security fixes will have effect on other applications, not just applications that use an embedded IE, but all applications that use WinInet. So I spend half a day figuring out what to do. And in the end I found out that using “http://www.google.com” as the cookie domain works as well.
[Now playing: The Project Hate MCMXCIX - With Desperate Hands So Numb]
Thank you for describing your experiences. To figure out what is going on in this API it helps to understood how the API is used by IE, specifically that the URL field is the url that the user navigates to when browsing to a site. The .google.com field you mention is in the cookie data. The set cookie API takes the URL and the cookie data and figures out what Domain and Path are and then does a security check that that Domain matches the URL’s domain. When figuring out the Domain and Path, the cookie data gets priority over what comes out of the URL. The API assumes that the URL is a valid URL, so you need a scheme and host and everything else. The behavior of the API when you don’t pass in a valid URL is undefined. It happens that with IE7’s support for IDN we actually test the URL hostname’s validity more in the UNICODE api (because we need to convert the hostname to IDN form).
Since you have the cookie and you aren’t actually naviagting to a site, you need to make up a URL that matches the cookie.