Deep analysis to understand the role of session and Cookie

In the history of Web development, the session and cookies are great exist, the original intention is to remember the user's browsing information on the site, if there is no other alternative, almost all Web sites are inseparable from sessions and cookies.

Why need

The HTTP protocol is stateless and causes the server to be unable to tell who is browsing the Web page. In order to maintain the user's status in the website, such as landing, shopping cart, there have been four kinds of technology, respectively, are hidden form fields, url rewrite, cookies, session.

Cookies

To address the problem of the HTTP protocol being unable to maintain its status, Lou Montulli, an employee of Netscape Communications in 1994, applied the concept of "magic cookies" to Web communications. He tried to solve the web's first shopping cart application, and now the shopping cart became the backbone of the shopping site. His original documentation provides basic information about how cookies work, which was later incorporated as a specification into RFC 2109, the implementation reference document for most browsers, and eventually included in RFC 2965. Montulli is also granted a U.S. patent for cookies. The Netscape browser started to support cookies in its first release, and now all Web browsers support cookies. (Cookies and sessions are only introduced here)

What is it

A cookie is a small piece of text that a browser saves on a user's computer to keep the user's information necessary on the site. The Web page or server tells the browser to store the information according to certain specifications, and in all future requests, the information is automatically sent to the server in the HTTP request header, which the server will use to determine the different users. And the cookie itself is safe.

How to create

The WEB server creates a Cookie,set-cookie message header by sending an HTTP message header called Set-cookie, which is formatted as follows (the parts in brackets are optional):

set-cookie:value[; expires=date][; domain=domain][; path=path][; secure]
Value

The value part, usually a name=value-formatted string. In fact, this format is the format specified in the original specification, but the browser does not validate the cookie value in this format. In fact, you can specify a string that does not contain an equal sign, and it will be stored as well. However, the most common use is to specify the value of the cookie in the Name=value format (most interfaces only support that format).

The cookie that is sent back to the server contains only the value of the cookie setting, not the other options for the cookie, and the browser does not make any changes to the cookie and sends it back to the server intact. When multiple cookies exist, separate them with semicolons and spaces:

Cookie:name=value; name1=value1; Name2=value2/pre>

Cookie Expiration Time

If you do not set the cookie expiration time, the cookie is destroyed after the session is finished, called the session cookie. If you want to set the session cookie to a persistent cookie, simply set the expiration time of the cookie, which is a wdy, dd-mon-yyyy HH:MM:SS GMT date format value. Note that this expiration date is associated with a cookie that is identified with Name-domain-path-secure. To change the expiration date of a cookie, you must specify the same combination.

A persistent cookie cannot be changed to a session cookie unless the cookie is deleted and then the cookie is created again.

Domain Options

The Domian option sets the domain of the cookie, and only HTTP requests sent to this domain can carry these cookies. In general, domain is set to the domain name of the page where the cookie is created.

Large Web sites like Yahoo! have many name.yahoo.com forms of sites (e.g., my.yahoo.com, finance.yahoo.com, etc.). By setting the domain option for a cookie to yahoo.com, you can send the value of the cookie to all of these sites. The browser compares the value in domain with the requested domain name (that is, it starts at the end of the string) and sends the matching cookie to the server.

Path option

The path option is similar to the domain option, and only the HTTP request containing the specified path can carry these cookies. This comparison is usually done by comparing the value of the path option with the URL of the request from the beginning. If the character matches, the Cookie message header is sent, for example:

Set-cookie:namevalue;path=/blog
Therefore, HTTP requests containing/blog carry cookie information.

Secure option

This option is just a tag and has no value. A cookie containing the secure option can be sent to the server only if a request is created over SSL or HTTPS. The content of this cookie is of high value, and if passed in plain text, it is likely to be tampered with.

In fact, confidential and sensitive information should never be stored or transmitted in a cookie because the entire mechanism of the cookie is inherently unsafe. By default, cookies that are transferred on an HTTPS link are automatically added to the secure option.

Http-only

Http-only means to tell the browser that the cookie must not be accessed through JavaScript's Document.cookie property. This feature is designed to provide a security measure to help prevent Cross-site scripting attacks (XSS) theft cookies from being launched through JavaScript.

JavaScript Manipulation Cookies

In JavaScript, you can create, maintain, and delete cookies by using the Document.cookie property. This property is equivalent to the Set-cookie message header when the cookie is created, and is equivalent to a cookie message header when the cookie is read.

Delete Cookies

Sessions Cooke (session cookie) is deleted at the end of the session (browser shutdown).
The persistent cookie (persistent cookie) is deleted when the expiration date is reached.
If the number of cookies in the browser reaches a limit, the cookie is deleted to create a space for the new cookie.
Session
The session function is similar to the cookie, and is used to solve the problem that the HTTP protocol cannot maintain state. But sessions are stored only on the server side and are not transmitted over the network, so the session is relatively safe compared to cookies. But the session is dependent on cookies, and when a user visits a site, the server generates a unique session_id for the user and sends the SESSION_ID to the client as a cookie, All requests from future clients will automatically carry this cookie (provided that the browser supports and does not disable cookies).

Use the following diagram to see how the next session works:

How to use session when disabling cookies

Sometimes, in order for a secure browser to disable cookies, you can send session_id to the server by using the argument, and the session will work as usual.

Delete session

Sessions are automatically invalidated after a session is closed, and can be programmed on the server side if you want to manually delete the session. If PHP is doing this

$_session = Array ();
Session_destory ();