Copy an article that mainly looks at the cookie path and domain

Copy Here, reproduced, put here as a collection of their own it:)


What is a cookie?


you ask, what is cookies? A cookie is a small amount of data that a browser saves on a user's computer. It is associated with a specific Web page or Web site and is automatically passed between the Web browser and the Web server.

For example, if you are running a Windows operating system and using Internet Explorer to surf the Internet, you will find a subdirectory under your Windows directory called "Temporary Internet Files". If you have time to look at this directory, you will find some files in it, the file name looks like an e-mail address. For example, in this directory on my machine, there are "[email protected]" such files. This is a cookie file, where does this file come from? Guess, it comes from Microsoft's support site. By the way, this is not my email address, hereby clarified.

Cookies are a great solution for managing small, unimportant details that don't want to be kept in a central database. (This is not to say that everyone's name doesn't matter.) For example, the ever-growing custom service on the site can customize what they want to see for each user. If you are designing a site like this, then how do you manage this information: one user likes the Green menu bar, and the other likes red. It's really a tiring question. However, such information can be safely logged to the cookie and saved on the user's computer, and your own database space can be left to longer-lasting, more meaningful data.

fyi:cookies is often useful for security purposes. I don't want to go too far on this, just provide an example of how to use cookies that expire after a certain period of time to secure your site:

log in using the user name and password via SSL.
Check the user name and password in the server's database. If the login succeeds, create a message digest (such as MD5) of the current time label and save it in the cookie and server database. Keep the user's login time in the user record in the server database.
when each security transaction is performed (any transaction where the user is logged in), the message digest of the cookie is compared to the digest stored in the server database, and if the comparison fails, the user is directed to the login interface.
if the 3rd step checks through, then check whether the current time and the time of the logon time elapsed longer than the allowed length of time. If the user has timed out, then the user is led to the login interface.
if both steps 3rd and 4th pass, the login time is reset to the current time, allowing the transaction to occur. Those security sites that require you to log in, most likely using a similar approach as described here.
Composition of Cookies

cookies were originally designed for CGI programming. However, we can also use JavaScript scripts to manipulate cookies. In this article, we'll show you how to manipulate cookies using JavaScript scripts. (if there is a need, I may describe in a future article how to use Perl for Cookie management.) But if it is not, then I will teach you one hand: Take a closer look at cgi.pm. In this CGI package there is a cookie () function that can be used to create a cookie. However, let us first introduce the nature of cookies.

in JavaScript scripts, a cookie is actually a string attribute. When you read the value of a cookie, you get a string that contains the names and values of all the cookies used in the current Web page. Each cookie has four properties in addition to the name and value values. These properties are: Expires expiration time, path path, domain realm, and secure security.

expires– Expiration time. Specifies the lifetime of the cookie. The specific value is the expiration date. You must use this property if you want the cookie to exist longer than the current browser session. When the expiration date is over, the browser can delete the cookie file without any effect.

path– path. Specifies the Web page that is associated with the cookie. The value can be a directory, or a path. If http://www.zdnet.com/devhead/index.html establishes a cookie, then all pages in the http://www.zdnet.com/devhead/directory, and the pages in any subdirectory below the directory can access this cookie. This means that any page in Http://www.zdnet.com/devhead/stories/articles can access the cookie created by http://www.zdnet.com/devhead/index.html. But what if http://www.zdnet.com/zdnn/needs to access the Cookes set by http://www.zdnet.com/devhead/index.html? At this point, we want to set the path property of the cookie to "/". When specifying a path, cookies can be shared by all Web pages that have the same path in the URL from the same server. Now let's look at another example: if you want http://www.zdnet.com/devhead/filters/and http://www.zdnet.com/devhead/stories/to share cookies, set path to "/ Devhead ".

domain– domain. Specifies the associated Web server or domain. The value is a domain name, such as Zdnet.com. This is an extension to the Path property. What if we want catalog.mycompany.com to have access to cookies set by shoppingcart.mycompany.com? We can set the domain property to "mycompany.com" and set the Path property to "/". FYI: The cookie domain attribute cannot be set to a different value than the domain of the server where it is set.

secure– safe. Specifies how the value of the cookie is passed between the user and the Web server through the network. The value of this property is either "secure", or null. By default, this property is empty, which means that data is passed using an unsecured HTTP connection. If a cookie is marked secure, it passes data to and from the Web server over HTTPS or other security protocols. However, setting the secure property does not mean that others cannot see the cookie that is stored locally on your machine. In other words, setting the cookie to secure only guarantees that the data transfer process between the cookie and the Web server is encrypted, while the cookie file stored locally is not encrypted. If you want to encrypt your local cookie, you have to encrypt your data yourself.

Manipulating Cookies

keep in mind that a cookie is a string property of a document. To save a cookie, simply create a string with the format name=<value> (name = value) and then set the document's Document.cookie to equal to it. For example, if you want to save the user name that the form receives, the code looks like this:

Document.cookie = "username" + Escape (form.username.value); Here, it is important to use the escape () function because the cookie value may contain a semicolon, a comma, or a space. This means that when reading a cookie value, the value must be decoded using the corresponding unescape () function.

we certainly have to introduce the four attributes of a cookie. These properties are appended to the string value in the following format:

name=<value>[; expires=<date>][; domain=<domain>][; path=<path>][; Secure]

name =< value >[; expires=< date >][; domain=< domain >][; path=< path >][; security]
 

<value>,
the. toGMTString () method gets the date value in this GMT format. Square brackets indicate that this is optional. For example, the square brackets on both sides of [; secure] represent the need to put the cookie into a safe place; Secure "is added to the back of the cookie string value. If "; Secure "is not added to the cookie string, then this cookie is unsafe. Do not add angle brackets <> and brackets [] to cookies (unless they are the contents of certain values). When setting properties, unlimited properties can be set in any order.

Here is an example, in this case, the cookie "username" is set to expire after 15 minutes, can be accessed by all directories on the server, can be accessed by all the servers in the "mydomain.com" domain, security status is safe.

the constructor of the//Date () setting is in milliseconds
//. GetTime () method returns a time in milliseconds
//So to set 15 minutes to expire, take 60000 milliseconds by 15 minutes
var expiration = new Date (new Date ()). GetTime () + * 60000);
document.cookie = "Username=" + Escape (Form.username.value) + "; expires = "
+ expiration.togmtstring () + "; Path= "+"/"+"; _
domain= "+" mydomain.com "+"; Secure "; Reading the cookie value is a little bit like a trick, because you get all the cookies that belong to the current document at once.

//The following statement reads all cookies that are part of the current document
var allcookies = Document.cookie; now we have to parse the different cookies in the allcookies variable to find the specified cookie of interest. This work is simple because we can use the extended string support provided by the JavaScript language.

If we are interested in the previously assigned cookie "username", you can read its value using the following script.

//We define a function to read a specific cookie value.
function GetCookie (cookie_name)
{
var allcookies = document.cookie;
var cookie_pos = Allcookies.indexof (cookie_name);

//If an index is found, it represents the existence of a cookie,
//On the contrary, the description does not exist.
if (cookie_pos! =-1)
 {
//Put Cookie_pos at the beginning of the value, just add 1 to the value.
Cookie_pos + = cookie_name.length + 1;
var cookie_end = Allcookies.indexof (";", Cookie_pos);

if (cookie_end = =-1)
  {
cookie_end = allcookies.length;
  }

var value = unescape (allcookies.substring (Cookie_pos, Cookie_end));
 }

return value;
}

//Call function
var cookie_val = GetCookie ("username"), the Cookie_val variable from the above example thread can be used to generate dynamic content, or sent to a server-side CGI script for processing. Now you know the basic way to manipulate cookies using JavaScript scripts. But if you're like me, the first thing we're going to do is set up some interface functions to hide the trouble with cookies. However, wait a moment before you start programming. The work has already been done for you. All you have to do is to find these interface functions.

For example, in David Flangan's javascript:the Definitive guide 3rd Ed., you can find a good cookie application class in this book. You can also find examples of this book on the OReilly Web site. In the list of links at the end of this article, there are direct links to examples of these cookies.

Cookies Monsters

cookies have a bad reputation for some reason. Many people use cookies to do despicable things, such as traffic analysis, click-Tracking. Cookies are also not very secure, especially cookies that do not have a secure attribute. However, even if you use a safe cookie, if you share a computer with others, such as an Internet café, others can spy on the unencrypted cookie file on your computer's hard drive, and you may be able to steal your sensitive information. So, if you're a web developer, you need to think about these issues carefully. Do not misuse cookies. Do not store data that users may consider sensitive to be stored in cookies. If a user's social security number, credit card number, etc. are kept in a cookie, it is tantamount to putting the sensitive information under the window paper, which is tantamount to putting the user into great danger. A good rule is that if you don't want strangers to know about you, don't keep them in cookies.

In addition, there are some practical restrictions on cookies. Cookies remain on the computer and do not follow the user's path. If the user wants to change the computer, then the new computer cannot get the original cookie. Even if the user is using a different browser on the same computer, the original Cookie:netscape cannot read Internet Explorer cookies.

Also, users are reluctant to accept cookies. So don't assume that all browsers can accept the cookies you send. If the browser does not accept cookies, you must ensure that your Web site does not crash or break.

In addition, the Web browser may not be able to retain more than 300 cookies. There is no standard to specify when and how the browser will void cookies. So when the limit is reached, the browser is able to delete cookies efficiently and randomly. The browser retains cookies from a Web server, no more than 20, per cookie data (including name and value), no more than 4K bytes. (However, there is no problem with the cookie size in this article, it only takes up a K-byte and is stored in 3 3 cookies.) )

in short, be careful to keep cookies simple. Do not rely on the existence of cookies, do not store too much information in each cookie. Don't save too many cookes. However, in the hands of highly skilled web administrators, the concept of cookies is a useful tool to remove these limitations.







=============================

Summary:
http://www.abc.com/abc/and http://www.abc.com/def/can share cookies
http://www.abc.com/abc/abc and Http://www.abc.com/abc/def can share cookies
http://abc.abc.com/and http://def.abc.com can also share cookies
Presumably, shared cookies can be implemented between all URLs of a domain

can http://www.abc.com/abc/and http://def.abc.com/share cookies? It's supposed to be a good feeling.

Copy an article that mainly looks at the cookie path and domain