ASP 101 - Active Server Pages 101 - Web04
The Place ASP Developers Go!

Windows Technology Windows Technology
15 Seconds
ASP 101
ASP Wire
VB Forums
VB Wire
internet.commerce internet.commerce
Partners & Affiliates
ASP 101 is an site
ASP 101 is an site
Internet News
Small Business
Personal Technology

Corporate Info
Tech Jobs
E-mail Offers

ASP 101 News Flash ASP 101 News Flash

 Top ASP 101 Stories Top ASP 101 Stories
What is and Why Do I Need It?
An Overview of ASP.NET
Connections, Commands, And Procedures

The big picture
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates

Cookies Across Domains

Cookies Across Domains

by Chris Payne


We all know and love cookies, for the liberties they allow us, and their delicious taste. If you've ever tried to share your cookies, however, you know that it's not as easy as it sounds.

Okay, cutting the baker talk. Cookies are very useful for developers - keeping track of users, performing many functions cheaper than more expensive databases, personalization and customization, etc. Cookies are not transferrable across domains; the only domain that can access the cookie is the domain that created it. This article takes a look at how to bypass this limitation using Active Server Pages.

Cookies - A Brief Introduction

We're going to take a short detour and explain cookies a bit, and show you briefly how to manipulate them using ASP.

A cookie is a small file that is stored on a client's computer. That means that whenever a user visits your web site, you can secretly stash a file with information on their hard drive. This file can contain almost any information you want - including user info, site statistics, or even your own name, for those with vanity problems. We can see how this could potentially be an easy target for hackers because of the possibilities it opens up.

One security trick to prevent abuse is that cookies can only be accessed by the domain that created them. This means that, for example, can only access (read from and write to) cookies that created. Generally, this is not a problem at all, but what if you work on two different sites on different domains that share user info, that is stored in cookies? You could, of course, just duplicate user info, but what if you want the user to only have to register on one site, and be automatically registered on the other? Or if they share the same user database, and you want to auto-login users? Sharing cookies across domains is ideal for this situation.

Before we get into that however, let's briefly show some ASP code that can manipulate cookies, so we have something to refer to later in the article.

'To write a cookie
Response.Cookies("MyCookie").Expires = Date + 365
Response.Cookies("MyCookie").Domain = ""
Response.Cookies("MyCookie")("Username") = strUsername
Response.Cookies("MyCookie")("Password") = strPassword

Reading and writing cookies is very simple. The above code sets a few properties for the cookie, the expiration date and the domain, and also sets a few values to be stored in the cookie. In this case, strUsername, and strPassword are variables we assigned somewhere earlier. Then, to read from a cookie, you simply request the values:

'To read a cookie
datExpDate  = Request.Cookies("MyCookie")
strDomain   = Request.Cookies("MyCookie").Domain
strUsername = Request.Cookies("MyCookie")("Username")
strPassword = Request.Cookies("MyCookie")("Password")

For more detailed code using ASP, check out this sample on ASP 101.

The Easy Way

The secret to sharing cookies easily is redirection. Here is the general procedure:

  1. A user hits
  2. If user does not have cookie for then redirect user to
  3. If user has a cookie for then redirect back to with a special identifier (explained below), else, just send user back to
  4. Write cookie on

Sounds pretty simple, huh? Let's expound a bit: and share the same set of users, and therefore if someone has a cookie (and is registered) at, then wants to be able to view those cookies as well, and provide whatever features the cookies allow. This way, visitors to will have a similar experience to those at

The key to this checking should be done in a file that you include on your pages on Let's take a look at the code on

Table 1.1
'Check for a cookie
If Request.Querystring("Checked") <> "True" then
	If not Request.Cookies("SiteA_Cookie").Haskeys then
		'redirect to
	End if
End if

If the user already has a cookie for, then we don't need to do anything - simply process the rest of the page. The first if statement is used to eliminate infinite loops, and doesn't really make sense by itself. Let's look at cookie.asp on to gain a better understanding:

Table 1.2
'Check for a cookie
If not Request.Cookies("SiteB_Cookie").Haskeys then
	'redirect to
	Response.Redirect("" _
		& "?checked=True")
	'grab username
	strUsername = Request.Cookies("SiteB_Cookie")("Username")
	'send back to with unique identifier
	Response.Redirect("" _
		& "?checked=True&identifier= & strUsername)
End if

If the user also doesn't have a cookie on, then send them back to and let the application know that you've already checked for the cookie by supplying a variable called "checked" in the querystring. Otherwise, it will send the user right back to, and you'll end up with an infinite loop.

Note: You can be sneaky here and redirect the user back to a registration page, or something similar. If you have an aggressive customization scheme going, you can do interesting things by displaying different message (for instance, "special deals" for an e-commerce site) based on the cookie information.

However, if the user does have a cookie on, we need to send the user back and let know about it. Hence, we attach a variable that uniquely identifies this user in our database, their username. Now, let's expand upon the code on The following code goes below what is already there in table 1.1:

Table 1.3
'Check for an identifier
If Request.Querystring("identifier") <> "" then
	strUsername = Request.Querystring("identifier")
	'perform some database stuff here (optional)
	Response.Cookies("SiteA_Cookie").Expires = Date + 365
	Response.Cookies("SiteA_Cookie").Domain = ""
	Response.Cookies("SiteA_Cookie")("Username") = strUsername
End if

Finally, we're back on The first part of this file (as written in table 1.1) would check to see whether the cookie check has been accomplished, and, since it obviously has (as indicated by the "checked" parameter in the querystring), we move onto the second part of the code displayed in table 1.3. If there is a specified identifier, then we can now build the cookie on Using the identifier (in this case, the user name), we could query a database or perform whatever manipulation we may need, if any at all. Then we set the cookie, and display the rest of the page. If there is no identifier specified, then we don't worry about any of this, and simply display the rest of the page as you would normally.

Voila! now has the same cookie as, and you didn't even have to break a sweat. You can transfer more data than simply a unique identifier, as we did, but here we wanted to keep the network traffic, as well as exposed data, to a minimum.

One thing to be aware of is that even if a user has a cookie on, you may still want to check Generally, this isn't necessary, and will save you and the user a little time, what if perhaps the user changed his/her personal info on This would be an easy way to make sure that all information is in sync.

Cookie Rings

To perform this little trick, we needed two files: one on the originating server (, to perform the check; and one on the reference server (, to validate the user. Note that you can potentially add as many originating servers as you want - if you have one reference server that contains all the cookies or user info you need, then all you need to do is add the file to all new servers that wish to share cookies.

This can also work in the opposite direction, for instance, if were the originating server, and had the user info. Users new to but familiar to could log onto and have all their familiar settings already pre-set for them. Note, however, that if you have more than one reference server, this can get quite confusing and resource demanding - you would have to redirect the user to each reference site to see if they exist.

Theoretically, you could have an entire network of sites that all share the same users. The most practical solution in this situation would be to create a ring of cookie sharing, or a cookie ring (you got to love these food analogies). Store a list of the reference servers in one place (the backbone server) that each reference server could look at to determine the next site to send the user to. Note that you would have to keep track of the original site the user started from, possibly by means of a querystring variable. In a world that's moving rapidly toward super-connectivity, this scenario becomes more and more feasible.


There are a few issues with this method, the foremost being the response times. The user will most likely never know what's going on, since the application is fairly transparent, but the load times they experience may be long depending on the connection between and, and even longer if you implement a cookie ring. Generally, it isn't a problem, but you can never predict network traffic.

Another major problem, that almost everyone who tries to implement this will probably face, is infinite redirects. This can happen for a number of reasons - a typo in the cookie scripts, if the user's browser doesn't support cookies, etc. Most likely it is a very simple problem to fix such as I've described, but don't be surprised if you see the status bar at the bottom of your browser go crazy with redirects when you try it out. Make sure you test this out on all available platforms and browsers before you implement this on a real site.

Finally, we can't forget about security. If some clever hacker found out about your little trick, it may be possible for them to sneak in and steal some cookies. A simple way to protect against this is to guard your reference server - only allow your originating server to access the cookies.asp file, or double check that the IP or referring address is acceptable.

Another Way

There is, of course, another way to perform this feat without resorting to redirection tricks. Unfortunately, though, it is more difficult. I won't go into depth in this article, but I will outline a few features.

The idea behind this second method is a component (a COM object) that resides on the reference server. When a user hits, you invoke a call to that component, or an ASP page on the reference sever, that invokes that component. This component then returns all the cookie information on for use on Note that this architecture is highly supported by the new Simple Object Access Protocol (SOAP), which allows applications to be used across the internet with simple XML. You could also implement the code on the originating server in a COM object as well.

This method offers several advantages over the previous redirection methods. First, there are no redirects involved, so you won't have to worry about infinite loops or excessive load times. There will be additional network overhead as you invoke the component, but no more than the previous method. Also, this method is much more secure and scalable - it allows for more servers to be added to the cookie ring easier and more reliably.


Sharing cookies is a very nice method to share user data and build a network of user friendly sites. Be careful, however, of user's privacy, as this is a great concern nowadays. Imagine, after all, if and teamed up to share user info in this way - one on hand, the companies would be able to offer the consumers more and better choices, but at what expense of the user's privacy? That, however, is another article.

Happy scripting!


Check out these links for further resources on manipulating cookies and topic covered in this article:

Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback
The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers