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, ytu.edu.cn can only access cookies created by ytu.edu.cn. 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 from the east to 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.
Reading and writing cookies is 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.
More detailed information, you can refer to the ASP data.
Realize
The trick to simply share cookies is to redirect them, and the general process is:
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 piece of code:
L-1
' Sitea.com ' Check cookies
If request.querystring ("Checked") <> "True" Then
If not Request.Cookies ("Sitea_cookie"). HasKeys Then
If the user has a sitea.com cookie, nothing needs to be done; The first if statement is used to eliminate an infinite loop. Let's take a look at the cookie.asp file on siteb.com to get a further understanding.
1-2
' Siteb.com
' Check cookies
If not Request.Cookies ("Slteb_cookle"). HasKeys Then
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.
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), complete the check, a reference server (siteb.com), authenticate 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 you have to redirect users 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.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
