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 ‘example.com’, the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.” – 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 http://onlinedev.garycrawford.co.uk 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 onlinedev.garycrawford.co.uk.
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 dev.garycrawford.co.uk pointing back to 127.0.0.1. Any sub-domain can be used hear as long as it doesn’t match the remotely running existing application: as 127.0.0.1 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: # # 22.214.171.124 rhino.acme.com # source server # 126.96.36.199 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 127.0.0.1 dev.garycrawford.co.uk
We then configure the project properties on the web application by setting the Start URL to http://dev.garycrawford.co.uk/DebugMultiSiteIntegrationSample.
When debugging in Visual Studio the application will now run at http://dev.garycrawford.co.uk. This means that by making http://dev.garycrawford.co.uk responsible for setting cookies – and scoping them to garycrawford.co.uk, 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.
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