If step 5 carries an expired cookie or an incorrect cookie, the authentication fails and is returned to the Request Authentication page.
There are two versions of the current Cookie: version 0 and version 1. There are two ways to set the identity of the response header, respectively, "Set-cookie" and "Set-cookie2". These two versions have different property entries, and table 10-1 and table 10-2 are descriptions of the properties for two versions.
Table version 0 Property entry Introduction
Property Item |
Property Entry Introduction |
Name=value |
Key-value pairs, you can set the Key/value to save, note that the name here cannot be the same as the names of other property items |
Expires |
expiration, the Cookie expires at a certain point in time, such as Expires=wednesday, 09-nov-99 23:12:40 GMT |
Domain |
The domain name that generated the Cookie, such as domain= "Xulingbo.net" |
Path |
The Cookie is generated under the current path, such as path=/wp-admin/ |
Secure |
If this property is set, the Cookie will be returned only when the SSH connection is made. |
Table Version 1 Property Entry Introduction
Property Item |
Property Item Introduction |
name=value |
Same as Version 0 |
version< /td> |
The response header created through Set-cookie2 must conform to the RFC2965 specification, if the default value is 0 through the Set-cookie response header setting, and if it is set to 1, the Cookie follows the RFC 2109 specification |
Comment |
Comment Item, user explains what the Cookie does for |
commenturl |
server for this &nbs P URI comment provided by cookie |
Discard |
whether to discard the Cookie entry after the end of the session, default to Fasle |
Domain |
similar to Version 0 |
max-age |
Maximum expiration time, unlike Version 0, where the number of seconds is set to expire |
Path |
similar to Version 0 |
Port |
The Cookie can be returned to the server under what port, if there are multiple ports, separated by commas, such as port= "80,81,8080" |
Secure |
similar to Version 0 |
The identifiers of header headers set in the above two versions of cookies are different, and we commonly use set-cookie:username= "Junshan"; Domain= "Xulingbo.net", which is the form of Version 0. This is set for Set-cookie2: Set-cookie2:username= "Junshan"; Domain= "Xulingbo.net"; max-age=1000. However, in the Java Web Servlet specification does not support the Set-cookie2 response header, in the actual application of some Set-cookie2 property items can be set in Set-cookie, such as set: Set-cookie:username= "Ju Nshan "; version= "1";D omain= "xulingbo.net"; max-age=1000.
The role of Cookies:
1. After the authentication (login) is resolved, the next visit also requires authentication (login) of the duplicate authentication issue.
2. You can remember the user name and password to enhance the user experience.
Disadvantages of Cookies:
1. Security issues
Cookie data is stored on the client side and may be tampered with or stolen.
Cookie data can be accessed, just as we can see all the cookie values in front of Firefox's plugin Httpfox. Not only can you view cookies, but you can even add and modify cookies through the Firecookie plugin, so the security of cookies is a big challenge.
In comparison, the security of the session is much higher, because the session is to save the data on the server, but only through a Cookie to pass a SessionID, so the session is more suitable for storing user privacy and important data.
2. The problem of large data transmission volume
Cookies allow the server-side program to keep track of each client's access, but each client's access must return these cookies, and if there are many cookies, this invisibly increases the amount of data transferred between the client and the server, and the Session appears to solve the problem.
The browser comes with all cookies with the same domain name, and if it is a level two domain name, the cookie for the top-level domain will also be included.
Each time the same client interacts with the server, it is not necessary to return all the Cookie values each time, but to return an ID, which is generated the first time the client accesses the servers, and each client is unique. This allows each client to have a unique ID, as long as the client returns the ID, which is usually a Cookie that is NANE to Jsesionid.
3. Browser limits the number and size of cookies
Three ways to work with the session:
1. URL-based Path Parameter, supported by default.
2. Based on cookies, it is supported by default if the cookie ID of the Context container is not modified.
3. SSL-based, not supported by default, only supported if Connector.getattribute ("sslenabled") is TRUE.
(HTTP request +cookie) interactive process