Is session used for the current website? No more cookies?

Are cookies useless?

Reply content:

Is the cookie useless?

It seems that no one focuses on it.

To put it simply, session stores the link status/data on the server. Cookies record the link status/data on the browser.

The HTTP protocol is stateless, that is, a browser requests a webpage. After receiving the webpage, the browser disconnects the link with the server and the server will not remember the link, when the browser sends a request again, the server always treats the request as a new request, and the server does not know what the browser has previously sent. For example, if a user logs on to the server, the connection to the server will be disconnected after the browser sends a user name and password Logon Request. When a request is sent again, the server does not know that the browser has logged on.

To solve this problem, the server adds a cookie to the HTTP header, which will be stored after the browser receives the cookie. Each time the browser sends a request, the cookie is sent to the server, then the server can use the cookie sent by the browser to know the request sent by the browser before (if the server records the request ). When it comes to login, after the browser sends a POST request to log on, the server returns a successful login and contains a random unique cookie, which will be sent by the browser for future requests, when the server reads this cookie, the server will know that this user has logged on before. Of course, cookies can also be used to store data on the browser side, and JavaScript on the browser side can read cookies, so some data can be stored and can be read when users access the Web page next time, for example, in some web games, you get the highest score, even the username and password (but HTML5 supports other methods, and fewer cookies are saved), and send them to the server, the server will ignore it.

Just now, when a user logs on, the server will allocate a unique cookie, so the server also needs to store the cookie. In addition, to record what the browser has done before, therefore, some requests sent under this cookie must also be recorded. For example, the user's previous page is under a certain page, after logging on, you need to jump back to someone else (that is, some requests sent by users, but is there any need to write temporary data into the database ). PHP and Java use this unique cookie (not necessarily a cookie, which is explained below) to access the data. The "interface" is called session. Basically, it is to declare certain pages to use sessions, and then you store data in these sessions. PHP will automatically help you generate a unique cookie and store the corresponding data of this cookie, the data is not sent to the browser. You don't need to know what the unique cookie is and where the corresponding data is stored. PHP and other servers will automatically help you deal with these operations. So, in fact, session is equivalent to PHP and so on to help you implement a database, store this cookie and its corresponding data, but the data is temporary and does not need to be permanently stored like a database. (If you want to store the data in cookies, it is also possible, but if you store too much data, it is a waste of bandwidth or something, in this way, the only cookie is the data sent each time. In addition, the data sent every time is not safe. Cookies can be forged on the browser. Therefore, all important data must be encrypted and stored in cookies. However, if you use a unique key and are afraid of cracking, using different keys is not convenient for management, in addition, encryption and decryption are a waste of computing resources, so the data is stored on the server)

What I just mentioned is that there is actually a URL rewriting method for the server to implement session through cookie. Each time the browser sends a request, there is actually another place where data can be stored, that is, the URL, so the unique identifier mentioned above can be included in the url of the webpage. Add this unique identifier at the end of the URL in the webpage. When the browser sends a request, the unique identifier will still be sent. For examplehttp://www.example.com/path/to/file.phpChangeHttp://www.example.com/path/to/file.php?phpsessionid=unique identifier. However, this method is fixed by manually converting the URL from each link on each webpage of the server code. It is obviously not convenient to use cookies.

Session is also implemented by cookie.

Cookies can store some data for a long time.
Session is short-term session data maintenance.
No conflict
Most sessions are implemented using cookies.

Both are useful and cannot be replaced.

Generally, a session only exists in the session period and does not exist once the session ends. Even if you do not end the session, it will be cleared after a certain period of time. Therefore, it can only be used to cache data that does not require persistence.

In addition to session, cookies can save data for a relatively long time. For example, you need to use cookies to maintain logon. Session IDs are also saved using cookies. However, this is done by php without your intervention.

Cookie

Cookie exists on the client. The client can read the content saved by cookies.
Each time a request is initiated, the client finds the cookie on the page and sends it to the server.
There are two types of cookie content changes:

1. When each request is sent, the server returns the content and sets the cookie.

2. The client's js scripts can also change the cookie.

Session

Saves the session id based on cookies.
Session access is on the server. The client does not know the session content, but does know the sessionID.
Each time a request is initiated, sessionID is sent to the server along with the cookie.
The session content can only be read and changed by the server.

The storage period is set accordingly. There is no such period of time as long or short. (For security issues, see the following)
Cookie is specified by the warranty (server or client). Each cookie content has a separate validity period;
The session is set on the server, and the validity period is for the entire session.

The cookie can be forged, and the session stored on the server cannot be tampered. Session content is safer.
Of course, you may say that the sessionID is saved in the cookie, and the cookie can be forged, so the sessionID can be forged.
Generally, it is difficult to forge a valid sessionID. Another question that comes out is that the hypothetical session has nothing to do with the question stem.

Only data that is used by the server and not required by the client is required. session is recommended. Sensitive data that you do not want the client to know is particularly useful.

Temporary Use of the client is required, and data stored on the server is not required. cookie is recommended. For example, temporary data for tracking user behavior in page statistics

In some cases, session or pure cookie can be used. In this case, we need to measure the usage based on the characteristics.
Generally, many sessions are used now, and the website does not lack the space resources.

Cookie: saves server resources, which can be valid for a long time and is not secure. Therefore, it is suitable for storing unimportant information.
Session: takes up server resources. It is valid and secure during normal user operations and is suitable for storing important information.

Sessions are stored on the server. Generally, session data is destroyed after the painting ends. Therefore, the life cycle is short and data cannot be stored for a long time.
Cookies are stored on the client side and can be used to store data for a long time.

• Session also requires support from cookies.

• It is not recommended to store things directly in cookies. session is preferred.

What if session needs cookies?

Cookies are certainly used. For example, after a website is logged on, a key is generated. In addition to being cached, the key also saves the related values to cookies. When you want to verify whether a user is logged on, directly obtain the corresponding cookie value, and then compare it in the cache

"Website login status is saved for 7 days", which requires COOKIE resolution. If session is used, because seesion is saved on the server, the server may be vulnerable to brute-force content.