Debugging Cookie Dependant Multi-site Integration in Visual Studio

November 4, 2012

New web applications must often integrate with existing websites. Achieving this is commonly dependant on the sites being able to set and consume cookies for each other. There are, however, clearly defined rules around the usage of cookies which can make developing and debugging the new application challenging. This post outlines the main challenge of developing and debugging cookie dependent multi-site integration – the domain restriction on cookies – and highlights an approach to overcoming this challenge in a debugging environment.

Cookie Domain Issue When Debugging

Cookies adhere to the “same origin policy”. This essentially means that browsers only pass cookies to the domain which set them, or potentially a sub-domain of that domain. In order to achieve this, the set-cookie response header has a Domain attribute which specifies the scope for the cookie. RFC 6265, which provides the definitive specification for cookies, states:

“The Domain attribute specifies those hosts to which the cookie will be sent.  For example, if the value of the Domain attribute is ‘’, the user agent will include the cookie in the Cookie header when making HTTP requests to,, and” – RFC 6265

This provides a degree of security for users of the www: if a browser adheres to this rule then cookies will never be transmitted to anywhere other than the domain for which it is scoped. However, this added security provides a challenge when debugging a site in Visual Studio which must integrate with a remote application through cookies: by default the debugging application’s domain is localhost – which will be a different domain from the remote application. This means that by default cookies cannot be set or consumed across the two applications.

For the purpose of this post, lets imagine that an instance of an existing application is running at with the purpose of enabling the developers to work on achieving integration. This means that the locally debugging instance – say http://localhost/DebugMultiSiteIntegrationSample – must be able to communicate via cookies set for the domain


This approach makes Visual Studio use a different application Url from the default localhost. We start by locating the dev PC’s hosts file. This can be found at: %SystemRoot%\system32\drivers\etc\hosts.

We then add an entry for pointing back to Any sub-domain can be used hear as long as it doesn’t match the remotely running existing application: as is a loopback address this would prevent you from being able to connect to the remote site.


# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#          # source server
#              # x client host

# localhost name resolution is handled within DNS itself.
#       localhost
#    ::1             localhost


We then configure the project properties on the web application by setting the Start URL to



When debugging in Visual Studio the application will now run at This means that by making responsible for setting cookies – and scoping them to, the TLD – we can ensure that cookies are transmitted in all communications with the local IIS server and the remote application.



Application Request Routing HttpModule

If you are using the ARR HttpModule in IIS, e.g. as a reverse proxy, you will need to uncheck “Reverse rewrite host in response headers” (see diagram below). Otherwise any Set-Cookie response headers will have their domain re-written before reaching the browser with potentially unintended side affects.



URL Rewrite HttpModule

If you are using the URL rewrite HttpModule in IIS, you will need to add conditions to prevent rewriting URL’s related to the remote application (see diagram below). This is also a common consideration when using the ARR HttpModule listed above as the Url Rewrite and ARR HttpModules are commonly used together to establish reverse proxies and SSL Offloading.



Pac File

If you have added a domain to the hosts file for debugging which also exists on the remote server, you may come across a scenario where you are still reaching the remote host rather than your locally running application. This is most likely because your pac file (proxy auto-config) is automatically sending you to the remote application. The Wikipedia article on pac files found here describes this in detail. You can confirm if this is in fact the issue, and reach a resolution, by inspecting your pac file (it’s simply a file containing some javascript). You are looking for an entry which exists for the domain in question within the “FindProxyForURL(url, host)” function. You can either comment out the entry or stop pointing to the pac file temporarily for debugging purposes.


This post has highlighted on of the issues with debugging multi-site integration across localhost and a remote application. The cause of the issue was described and an approach to resolving this issue was outlined. Some common “gotcha’s” were also detailed.

Hopefully this will help you with your next integration project! Happy coding :-)

tags: , , , ,
posted in Debugging, Integration by admin

Follow comments via the RSS Feed | Leave a comment | Trackback URL

2 Comments to "Debugging Cookie Dependant Multi-site Integration in Visual Studio"

  1. Mark wrote:


  2. Mark wrote:


Leave Your Comment