How to design a cookie across domains in ASP

Cookie Introduction

First, we have a simple introduction to cookies that explain how to use ASP to maintain cookies.

A cookie is a small file stored on a client computer, which means that whenever a user accesses your site, you can secretly place a file containing information about it on its hard disk. This file can contain almost any information you intend to set up, including user information, site status, and so on. In this case, there is a potential danger: this information is likely to be read by hackers. An effective way to prevent this from happening is that the cookie can only be accessed by the domain in which it was created. This means: For example, ytu.edu.cn can only access cookies created by ytu.edu.cn. Generally speaking, this is fine, but what if you need two different sites on two different domains to share the user information stored in the cookie? Of course, you can choose to copy the user's letter, but, if you need the user can only register on one site, and from the east to become a registered user of another site? Or, two sites share a single user database and require users to log on automatically? This is the best solution for sharing cookies across domains.

Here, let's look at some of the ASP's code for processing cookies for easy reference later.

' Create a cookie

Response.Cookies ("MyCookie"). expires=date+365

Response.Cookies ("Mycookle"). Domain= "Mydomaln.com"

Response.Cookies ("Mycookle") ("Username") =strusername

Response.Cookies ("Mycookle") ("Password") =strpassword

Read and write cookies are very simple, the code above creates a cookie and sets properties for the cookie: domain, expiration time, and other values stored in the cookie. Here, Strusename,strpassword is a variable set in the previous location. Then, read through the cookie in the following statement.

' Read cookies

Datexpdate=request.cookies ("MyCookie")

Strdomaln=request.cookies ("Mycookle"). Domain

Strusername=request.cookies ("Mycookle") ("Username")

Strpassword=request.cookies ("MyCookie") ("Password")

For more detailed information, you can refer to the data of ASP.

Realize

The trick to simply share cookies is to redirect, and the general process is:

1. A user clicks Sitea.com.

2. If the user does not have a sitea.com cookie, redirect the user to siteb.com.

3. If the user has a siteb.com cookie, the user is redirected back to sitea.com with a special logo (explained below), otherwise the user is redirected to sitea.com only.

4. Create a cookie in sitea.com.

It seems simple to analyze: sitea.com and siteb.com share the same user settings, so if the user has a siteb.com cookie (already registered), sitea.com can also read the cookie and provide the features allowed by the cookie. In this way, users accessing sitea.com are like visiting siteb.com. Shanghai Treatment Impotence Hospital}

This check should be done in a cookies.inc contained in the sitea.com file. Let's take a look at this piece of code:

L-1

' Sitea.com ' Check cookies

If request.querystring ("Checked") <> "True" Then

If not Request.Cookies ("Sitea_cookie"). HasKeys Then

' re going to siteb.com

Response.redlrect ("http://www.siteB.com/cookie.asp")

End if

End if

If the user has a sitea.com cookie, there is no need to do anything; the first if statement is used to eliminate infinite loops. Let's take a look at the cookie.asp file on siteb.com for further understanding.

1-2

' Siteb.com

' Check for cookies

If not Request.Cookies ("Slteb_cookle"). HasKeys Then

' Redirect to Sitea.com

Response.Redirect ("http://www.siteA.com/index.asp" & "? Checked=true")

Else

' Get username

Strusername=request.cookies ("Siteb_cookie") ("Username")

' Return the user along with a special flag to the sitea.com

Response.redlrect ("http://www.siteA.com/index.asp" & "? Checked=true" & "identrfer=" &strusername)

End if

If the user still does not have a cookie on the siteb.com, send him back to sitea.com and let the application know that you have checked the cookie by providing a parameter called "CHECKD" in the query statement. Otherwise, send the user back to siteb.com and exit the loop.

However, if the user has a siteb.com cookie, we need to send the user back to sitea.com and tell Sitea.com. To do this, we append a unique flag to the database, username. So, we extend the code in sitea.com.

L-3

' Sitea.com

...

...

' Check mark

If request.querystring ("identifier") <> "then

Strusername=request.querystring ("identifier")

' Log to Database

Response.Cookies ("Sitea_cookie"). expires=date+365

Response.Cookies ("Sitea_cookie"). Domain= "Sitea.com"

Response.Cookies ("Sitea_cookie") ("Username") =strusername

End if

Finally, we go back to sitea.com. The first part of the file (l-l) checks whether the cookie has been checked, as it is clear that it has been completed (indicated by the "checked" parameter in the statement), and is carried out to the second part of the program shown in L-3. If there is a special flag, we can create a cookie in sitea.com. Using this special flag (here is username), we can query the database whenever we need to. Then, set the cookie to show the rest of the page. If there is no flag specified, there is no need to worry, simply display the rest of the page.

Thus, effortlessly, sitea.com has the same cookie as siteb.com. We can transfer more information than just a sign, and control the network traffic to a minimum.

It is important to note that even if the user has a cookie on the sitea.com, they still need to check siteb.com. Generally speaking, this is not necessary, it will save time. However, once the user changes the personal information in siteb.com, this will keep all information in sync.

Cookie Ring

To accomplish this, we need two files: one at the original site server (sitea.com), complete the check, and one on the reference server (siteb.com) to authenticate the user. If you have a reference server that contains all the user information or cookies that you need, you can add a random number of original servers, and all you need to do is add the Cookie.inc file to the server where you want to share the cookie.

It can also be performed in reverse order, for example, if Siteb.com is the original server and sitea.com contains user information. Users who have visited sitea.com but have never visited siteb.com can log in to sitea.com and have all of their previous settings. Note that if you have multiple reference servers, this can be confusing and consumes too much resources because users must be redirected to each reference server.

Theoretically, you can have a network where all sites share the same user. The most feasible option is to create a shared cookie ring. Store the list of reference servers in one place (backup server) so that each reference server can find and decide to redirect the user's next site. Remember to keep track of which origin server the user is starting with by querying the string. This information is transmitted very quickly, and this link becomes more and more feasible.

There are some problems here, first of all the reaction time. For users, they'd better not know what the process is. The time he needs depends on the connection between Sitea.com and siteb.com, which is likely to be longer and may take longer to implement the cookie ring.

Another major problem is that every one of them will face infinite redirects. There are many reasons for this, such as: The user's browser does not support cookies. This requires a redesign of the code to monitor the performance of the user's browser.

It is best to pay attention to security issues. If some hackers find the trick, he may get the information in the cookie. The simplest precaution is to protect the reference server, allowing only the original server to access the cookie.asp file.

How to design a cookie across domains in ASP