Do you use the session for the website now? No more cookies?

Is the cookie useless?

Reply content:

Is the cookie useless?

No one seems to be talking about the point.

Simply put, the session stores the link state/data on the server side, and the cookie is the link state/data that is recorded on the browser side.

HTTP protocol is stateless, that is, a browser to request a Web page, after receiving the Web browser disconnected from the server, the server will not remember the link, when the browser sends the request when the server always take this request as a new request, the server does not know what the browser has sent before. For example, the user login This problem, when the browser sends the user name password login success, will be disconnected from the server, then send the request when the server actually did not know that the browser login.

So in order to solve this problem, the server added a cookie in the HTTP header, and the browser will store it when it is received. The browser sends this cookie to the server each time a request is sent, and the server can send a cookie via the browser to know what request the browser has previously sent (if the server has logged it). When it comes to login, after the browser sends a POST request login, the server returns a login success, and contains a randomly generated unique cookie, then the browser will send this cookie, the server read the cookie, then the server will know that the previous user logged in. Of course, cookies can also be used to store data on the browser side, JS in the browser can read cookies, so you can store some data, such as the next time users visit the Web page can be read, for example, some pages of the game you have won the highest score, Even the user name and password (but HTML5 support other ways, save less and fewer in the cookie), sent to the server side, the server ignored just.

Just said log in, the server will be assigned a unique cookie when the user logs in, then the server must also store this cookie, and in order to record what the browser has done before, it is also necessary to record in this cookie sent some requests, For example, the user login before the page is a page, log in after the need to give someone to jump back to AH (that is, some users have sent a request, but there is no need to write to the database temporary data). Php,java through this unique cookie (not necessarily a cookie, as explained below) access to the data "interface" is called session. Basically is to declare some pages to use the session, and then you store the data in these sessions, PHP will automatically help you to generate a unique cookie and store the cookie corresponding data, and this data is not sent to the browser side. You do not need to know what this unique cookie is and where the corresponding data is stored, and the server such as PHP will automatically help you with these operations. So, in fact, the session is equivalent to PHP to help you implement a database, store this cookie and its corresponding data, but these data are temporary, do not need to be like a database of permanent preservation. (If you want to store this data in a cookie is also possible, but if the data stored too much is also a waste of bandwidth, and so the implementation of the data sent each time is only the only cookie, and each time the data sent is not too safe after all. Cookies can be forged on the browser side, so all important data must be encrypted in the cookie, but if the use of a unique key and fear of cracking, the use of different keys is not easy to manage, and encryption and decryption are wasted computing resources, so the data is stored on the server side bar)

Just said that the server test cookie implementation session, in fact, there is a way to implement the URL rewrite session. Every time the browser sends a request, there is actually a place where the data can be stored, that is, the URL, so the unique identifier above can be found in the URL of the Web page. Add this unique identifier at the end of the URL in the Web page, and the browser will send the unique identity to the past when it sends the request. Like turning it http://www.example.com/path/to/file.php into a http://www.example.com/path/to/file.php;PHPSESSIONID=唯一标识 . But this way there is a certain, it is necessary in the server-side code of each page of the link to the completion of the conversion of this URL, it is obvious that the use of cookies is not convenient.

The session is also implemented by cookies.

Cookies can keep some data for a long time
Sessions are short-term maintenance session data
The two do not conflict
Most sessions are implemented with cookies.

Both are useful and cannot be substituted.

In general, the session only exists in the conversation period, and once the end session does not exist. Even if the session does not end, it is usually cleared after a certain amount of time, so it can only be used to cache some data that does not need to be persisted.

Cookies can be stored for a relatively long period of time, in addition to being in session. For example, if you want to keep logged in, use cookies. Session ID is also saved with a cookie, but this is PHP's own do not need your intervention.

Cookies

The cookie exists on the client. The client can read the cookie to save the content.
Each time the request is initiated, the client finds the page's cookie to the server.
There are two general changes to the content of cookies:

1. On each request, the server returns content and sets a cookie.

2. The client's JS script and the like can also change the cookie

Session

A cookie-based ID used to hold the session.
Session access is on the server. Customer service side do not know session save content, but know SessionID.
Each time the request is initiated, SessionID is passed to the server with the cookie.
Session content can only be read and changed by the server.

The retention period has a corresponding setting, there is nothing to save for a long time, that short. (But there is a security issue see below)
The cookie is specified by the depositary (server or client) and each cookie content has a separate validity period setting;
The session is set on the server and is valid for the entire session.

A cookie can be forged, and the session is saved in a server that cannot be tampered with. Session save content is more secure.
Of course, you read the above may say: SessionID stored in cookies, cookies can be forged, so you can forge SessionID ah.
In general, it is difficult to forge a valid SessionID. Another problem that leads to the falsification of the session is not to repeat it.

Only need to use the server, the client does not need data, recommend the session. Sensitive data that you do not want the client to know is especially appropriate.

Requires temporary use of the client, does not require the server to save the data, recommend the use of cookies. For example, temporary data tracking user behavior in page statistics

In some cases, a session or a pure cookie can be used, at this time to combine features to measure the adoption of what.
Generally now use the session more, and now the site is not lack of space resources

Cookies: Save server resources, can be long-term effective, unsafe, suitable for the storage of unimportant information.
Session: Occupies the server resources, the general user operation period is effective, safe, suitable to store important information.

Session is the server side of the data to save sessions, usually the end of the painting will be destroyed, so the life cycle is very short, can not save data for a long time.
Cookies are stored on the client side and can be stored for long periods of time.

• The session also requires the support of the cookie technology

• It is not recommended to store anything directly in the cookie, the preferred session

The session needs to use cookies.

Cookies are definitely used, such as when a website is logged in, generate a key,key in addition to the cache, will also save the relevant values to the cookie, when you want to verify that the user is logged in, directly take the value of the corresponding cookie, and then in the cache comparison

"Site Login status for 7 days", this depends on cookie resolution, if the session, because Seesion is stored on the server, the servers will have the risk of the content of the plug-in

