Enable cookies to function across domains

All Web developers will love the powerful nature and ease of use of cookies, which have a powerful role in tracking user information, building personalized, personalised web sites, and avoiding the expensive cost of using a database. However, cookies cannot be passed across domains, only those domains that create it can be accessed; here we discuss how to use ASP to break through this limitation.

Introduction to Cookies

First, let's make a simple introduction to cookies, explaining 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 the information on its hard disk. This file can contain almost any information you intend to set, including user information, site status, and so on. In this case, there is a potential danger: this information may be read by hackers. An effective way to prevent this problem is that cookies can only be accessed by the domain in which it was created. This means that, for example, lucky.myrice.com can only access cookies created by lucky.myrice.com. Usually, there is no problem with this, but what if you need two different sites on two different websites to share user information stored in cookies? Of course, you can choose to copy the user letter, but if you need a user can only register on one site, and automatically become another site registered users? Or, two sites share a user database and require users to log in automatically? This is the best solution for sharing cookies across domains. Here, first look at some of the ASP processing cookies code to facilitate reference later.

' Create a cookie response.cookies (' MyCookie '). expires=date+365 response.cookies ("Mycookle"). Domain= "mydomain.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 the properties for the cookie: domain, expiration time, and other values stored in the cookie. Here, the Strusename,strpassword is a variable that was set up somewhere before. Then, read through the cookie in the following statement. "Read the cookie datexpdate=request.cookies (" MyCookie ") strdomaln=request.cookies (" Mycookle "). Domain strusername=request.cookies ("Mycookle") ("Username") strpassword=request.cookies ("MyCookie") ("Password") More detailed information, you can refer to the ASP data. The trick to implementing a simple sharing cookie is redirection: 1. A user clicks on the sitea.com. 2. If the user does not have a sitea.com cookie, redirect the user to the siteb.com. 3. If the user has a siteb.com cookie, the user is redirected back to the sitea.com with a special flag (explained below), otherwise, the user is redirected to the sitea.com only. 4. Create cookies in sitea.com. It looks very simple: 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 properties allowed by the cookie. This allows access to sitea.com users as if they were visiting siteb.com. This check should be implemented in a cookies.inc in the file contained in sitea.com. Let's take a look at this code: L-1 ' sitea.com ' Check cookies If request.querystrinG ("Checked") <> "True" then If not Request.Cookies ("Sitea_cookie"). HasKeys then ' back to siteb.com response.redlrect ("[url=http://www.siteb.com/cookie.asp]http://www.siteb.com/ Cookie.asp[/url] "End If" if the user has a sitea.com cookie, then nothing needs to be done; The first if statement is used to eliminate infinite loops. Let's take a look at the cookie.asp file on siteb.com to get a further understanding. 1-2 ' siteb.com ' checks cookies If not Request.Cookies ("Siteb_cookle"). HasKeys Then ' redirect to Sitea.com Response.Redirect ("[url=http://www.sitea.com/index.asp]http://www.sitea.com/ Index.asp "&" Checked=true[/url] "Else" Get Username strusername=request.cookies ("Siteb_cookie") ("Username") " Return the user with a special flag to sitea.com response.redlrect ("[url=http://www.sitea.com/index.asp]http://www.sitea.com/index.asp" & "? Checked=true" & "Identrfer=" &strusername[/url]) 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 attach a unique logo to the database, username. So, we extend the code in sitea.com. L-3 ' SiTea.com ... ' Check flag 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 return to sitea.com. The first part of the file (l-l) checks whether the cookie has been checked and, since it is clear that it has been completed (as indicated by the "checked" parameter in the statement), proceed to the second part of the program shown in L-3. If there are special flags, we can create cookies in sitea.com. Using this special logo (here is username), we can query the database whenever we need it. Then, set the cookie to display the rest of the page. If no flags are specified, there is no need to worry, as long as the remainder of the page is simply displayed. In this way, effortlessly, sitea.com has the same cookie as siteb.com. We can transfer more information than just a flag, and control the network traffic to a minimum. Note that even if the user has a cookie on the sitea.com, it still needs to check siteb.com. Generally speaking, this is not necessary, also will save time. However, once the user changes the personal information in the siteb.com, doing so will keep all information synchronized. Cookie ring To complete these, we need two files: one at the original site server (sitea.com), completing the check, a reference server (siteb.com), authenticating the user. If you have a reference server that contains all the user information or cookies you need, you can add a random number of original servers, all you need to do is add cookie.inc files to all servers that share cookies. You can also perform 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 also log on to sitea.com and have all the previous settings. Note that if you have more than one reference server, 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 users. The most feasible solution 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 on the next site for the redirected user. Remember to keep track of which original server the user is starting with by means of a query string. This information is transmitted very quickly, this link becomes more and more feasible. There are some problems here, first of all, 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 can be longer and may be longer when the cookie loop is implemented. Another major problem is that every one of them will face infinite redirects. There are a number of reasons for this, for example: The user's navigator does not support cookies. This requires the redesign of code to monitor the performance of the user's browser. It's best to be aware of 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.