Monthly Archives: June 2010

Forwarding cookies

Sometimes we come across integration scenario’s that look straighforward, but where the devil is in the details. We needed to integrate our application in an existing ASP “classic” site (yes, the still exist). The catch was that we needed to call the ASP “classic” site in a server to server call to get some information, but we needed to do this under the context of the current user. You may be wondering why we didn’t go through a shared database or someting, but the problem is that there is little knowledge left of the old app, so changing the existing app was a no go.
So, in order to impersonate the user, you need your server-sided request look like that user. This means forwarding the cookies the user sends, and sending back the cookies the server sends to the user. Below is code that demonstrates that.

HttpWebRequest webRequestToServer = (HttpWebRequest)HttpWebRequest.Create("http://somedomain/somepage.asp");
webRequestToServer.CookieContainer = new CookieContainer();
foreach (String cookieKey in Request.Cookies)
    HttpCookie cookie = Request.Cookies[cookieKey];
    Cookie serverCookie =new Cookie(cookie.Name, cookie.Value, "/", "somedomain");
HttpWebResponse webResponseFromServer = (HttpWebResponse)webRequestToServer.GetResponse();
foreach (Cookie serverCookie in webResponseFromServer.Cookies)
    HttpCookie clientCookie = Response.Cookies[serverCookie.Name];
    if (clientCookie == null)
        clientCookie = new HttpCookie(serverCookie.Name);
    clientCookie.Value = serverCookie.Value;
    clientCookie.Expires = serverCookie.Expires;

This code works fine in a test environment, but there is a catch… in some cases the domain of the server is not set in the cookie you get on the server side. The problem with that is that when you set the domain, it doesn’t correspond to what the server expects. You can see this if you write out the cookies you send/receive (both on the browser connection and te server-server connection) to a log or something (including the domain. It took a while to figure out, but replacing “somedomain” with Request.ServerVariables["LOCAL_ADDR"] did the trick.

Microsoft and Apple promote Android phones

An important reason I have a Windows phone is because I have control over which applications I buy and from whom. I decide what I can or cannot install on my phone. With Windows Phone 7 Series Microsoft is blocking this “sideloading”, so users can only download and install new software through Marketplace. Basically Microsoft is following the Apple iPhone model with this, and the reason is for this is clear: follow the money. Microsoft has realized that Apple is making millions of dollars from the percentage they get on apps sold through the app store. This is logical, because ultimately it is not your device that makes the difference, but what you can do with it. Functionality and content sell, it’s as simple as that.
As I said an important reason for me to have a Windows phone, and not an iPhone, was the control I have over my device. I think I am not alone in this, and I’ve heard a lot of people using Apple products (iPhone in particular) complain about this too. It’s the one thing the makes Apple impopular compared to Microsoft, so I guess Microsoft just wants to be the impopular company. Windows Phone 7 Series will also be impopular to vendors. On that front Microsoft is thightning the screws as well. Microsoft now determines the hardware specs and as vendor you have little options to alter the appearance of the OS. This means there are less options to differentiate yourself from competitors.
I think the new Microsoft policy will ultimately drive people away, rather than gain momentum. It will drive people to Android based phones where phone vendors and users are still in control. If you look at the momentum Android already has, more people will also choose Android over iPhone for the same reasons.