Here, There, and Back Again: Maintaining State Across Domains

	Here, There, and Back Again: Maintaining State Across Domains
These three simple techniques combine persistent cookie management and creative redirects to give users a consistent experience as they move through sites in different subdomains and domains. By Justin Whitney

ife gets more complicated every day, whether you’re trying to maintain the state of a user’s activity or a healthy state of mind. In today’s cooperative environment of ASPs, shared services and strategic partnerships, the task of following a user’s context is becoming trickier than simply setting a Session variable or some cookies. Nowadays, your user may visit different subdomains or even different domains altogether and still expect you to keep up with her or lose her forever.

Here are three simple techniques, each building on the next, that combine persistent cookie management and creative redirects to give your user a consistent experience and allow sites in different subdomains and domains to interoperate.

Technique 1: Master of your .domain
When you have multiple subdomains, use the .domain property to specify the root domain of the cookie. For example:

   Response.Cookies("CustomerID").Domain = "mycompany.com"
   Response.Cookies("CustomerID") = 12345
   Response.Cookies("CustomerID").Expires = #Dec 31, 2050#

Note that this only needs to be done once per page but must be done before any cookie-write attempts. Without specifying a domain, the cookie in this example can only be read from the subdomain on which it was created. In this case, suppose you set a CustomerID cookie in a page on members.mycompany.com, but you don’t assign a domain. Trying to read the cookie using Request.Cookies(“CustomerID”) from store.mycompany.com will result in an empty string, even though it works fine from the original page. In contrast, specifying the domain allows the cookie to be read from either subdomain without a problem.

As you can imagine, this sort of thing is very difficult to debug. Start using the domain cookie property now to save yourself some headaches down the road. See the sidebar Debugging Cookies and Redirects for some useful ways to debug cross-domain cookies. One brief word of warning: during development and testing, you MUST use a resolvable domain when navigating your site in order for the domain property to function properly. If you use an internal address such as http://testsite/, the cookies will crumble in unexpected ways. Instead, use a full domain, even if it’s only resolvable on your company’s network. Use something like http://www.mycompany.com/testsite or http://testsite.mycompany.com.

Next

Technique 1: Master of your .domain

Technique 2: Where Did I Go Today?

Technique 3: The Boomerang

TALK BACK

Have you ever used the techniques described in this article? Are you using other methods for maintaining user state information across domains? Join the DevX ASP community at devx.web.asp to get answers, make comments, or help others with their problems.