Session is the server solution to HTTP stateless problem, cookie is the client solution to HTTP stateless problem

What is a cookie?

Since the HTTP protocol is stateless, the business on the server side must be stateful. The original purpose of cookies was to store state information in the Web for easy use on the server side. Such as determining whether a user is visiting the site for the first time. A cookie is a text file that is kept on the client’s hard drive (if the cookie’s expiration time is set) or in the user’s browser memory (if the cookie is temporary). This file is transparent to the user, and you can use the browser tools to view the current cookie, maybe more than one.

Cookie processing is divided into:

The server sends the cookie to the client and the browser saves the cookie and every time the HTTP request is made the browser sends the cookie to the server

When are cookies saved in the browser?

This is an important question, because browser cookie values don’t just happen. The server sends the Cookie to the client through HTTP response packets. Set the Cookie to be sent to the client in set-cookie format as follows:

setcookie('xxx'.'yyyyyyyyyyyyy');    
Copy the code

When the user accesses the program for the first time, the setcookie function generates a cookie file and stores it in the browser’s Response Header. Note that if the user accesses the global data $_COOKIE in the server, the array will be empty. At this point, the client has not passed the cookie information to the server.


Cookie format is as follows

“name=value; domain=.domain.com; path=/; expires=Sat, 11 Jun 2016 11:29:42 GMT; HttpOnly; secure”

Name =value is mandatory and other options are optional. The main components of a Cookie are as follows: Name: indicates a unique Cookie name. Cookie names are generally case insensitive. Value: string value stored in cookies. It is best to urL-encode the name and value of the cookie. Domain: The domain for which the cookie is valid. This cookie information is included in all requests sent to the domain. This value may or may not include a subfield (such as yq.aliyun.com, which is valid for all subfields of aliyun.com). Path: Represents the path affected by the cookie. Based on this configuration, the browser will send the cookie to the path matching the specified field.

Expires: A timestamp that indicates when the cookie should be deleted (that is, when it should stop sending the cookie to the server). If you do not set this timestamp, the browser will delete all cookies when the page closes; But you can also set your own deletion time. This value is in the GMT format, and expires can be biased if the client and server time are inconsistent. HttpOnly: tells the browser that it is not allowed to change this value through the document.cookie script and that this value is also not visible in document.cookie. But HTTP requests still carry this cookie. Note that although this value is not available in the script, it still exists as a file in the browser installation directory. This setting is usually set on the server side. Secure: indicates the security flag. If this parameter is specified, the message is sent to the server only when SSL links are used. If HTTP links are used, the message is not transmitted. The secure property does not mean that others cannot see the cookies stored locally on your machine, so do not put important information in cookies

Use cookies to achieve user login

The request header carries a cookie when the request is of a cross-domain type

When xhr.withCredentials = true is configured, the response header access-Control-allow-origin must be added at the back end, and the domain name must be specified instead of *. Otherwise, the following error occurs

What is a sessionID?

Session technology is a server-side solution that maintains state through the server. Where the session is stored: Memory on the server side. However, sessions can be persisted in a special way (memcache, Redis).

Where does the sessionID come from and how is the sessionID used? When a client requests a session object for the first time, the server creates a session for the client and calculates a sessionID through a special algorithm to identify the session object

The relationship between cookies and sessions

Cookie and session schemes belong to the client and the server respectively, but the session implementation of the server is dependent on the cookie of the client. As I mentioned above, when the server implements the session mechanism, the SESSION ID value will be generated and sent to the client. The client will put the ID value in the header of the HTTP request and send it to the server. The id value will be saved on the client in the container of cookie. Therefore, when we completely disable the cookie of the browser, the session on the server will not be used normally (note: Some sources say that ASP solves this problem, when the browser cookie is disabled, the server session can still be used normally, I have not tested ASP, but for many web sites written in PHP and JSP, I found that the website session can not be accessed normally if the cookie is disabled.

Cookie setting, reading, and whether to carry automatically

Blog.csdn.net/weixin_3380…

With token, sessionId, RSA encryption login authentication and security solution

www.cnblogs.com/yyjie/p/749…

Reference: blog.csdn.net/zhangquan_z…

Blog.csdn.net/awhip9/arti…

www.cnblogs.com/wszz/p/7778…