Capture the session and cookie to be logged on to the page

Consider one question: how to capture a restricted webpage? For example, the homepage of a friend on campus and a personal new page.

Obviously, in the browser, We can manually enter the user name and password to access the target page. The so-called "crawling" only requires the program to simulate the same job, therefore, you need to know what happened during the "login" process.

For Unlogged users, the server forces the user to jump to the login page. The user enters the user name and password and submits the request. The server compares the user post information with the information in the database. If the user passes the request, the server redirects to the landing page. How does the server determine our identity when we access other pages? Because the HTTP protocol is stateless, it is clear that the server cannot directly know that we have logged on successfully in the last second.

The simplest way of thinking is that each POST request must contain a user name and password to identify the user. This is feasible, however, this greatly increases the server load (Database verification is required for each request) and greatly reduces the user experience (the user name and password need to be re-entered on each page, every page has a logon form ).

Therefore, a solution was created: cookie. Cookie, in short, stores some historical user operation information (including logon information) on the local computer, and sends the local cookie content to the server through HTTP when the user visits the site again, to complete the verification or continue the previous step.

Further, another solution was created: Session, in short, stores the historical information of user operations on the server. However, in this method, the client sending the request corresponds to the Session object. Therefore, you can use the cookie mechanism to obtain the Client ID (session ID ), you can also submit the ID to the server by using get. Session ID, that is, the name of the session object file on the server. It is generated by the server to ensure randomness and uniqueness. It is equivalent to a random key and avoids exposing the user's real password during handshaking or transmission, similar design ideas are often used in SSO and openid.

Insert another question: why does the session become invalid after the browser is closed for some websites? Metropolitan entertainment city

As you can see from the above, the session generally saves the session ID through the cookie. If the cookie is set to disable the browser, the session will be deleted (expire). Then no matter how you set the Session Timeout mechanism, because the original cookie cannot be found again when the browser restarts, the server can only re-allocate the session ID for it.

What is the difference between cookie and session?

Session and cookie share the same purpose. They both aim to overcome the stateless defect of the HTTP protocol, but the methods for completing the process are different. The session uses cookies to save the session ID on the client, and stores other session messages of the user in the session object on the server. In contrast, the cookie needs to save all information on the client. Therefore, cookies have certain security risks, such as deciphering the user name and password stored in local cookies, or collecting cookies by other websites (for example, 1. appa takes the initiative to set Domain B cookies for Domain B cookies to be obtained; 2. XSS, get document on Appa through JavaScript. cookie and pass it to your APPB ).

When I first wrote the PHP app, I knew that I could get the userid from the session through SSO, but I didn't know why. So I encountered a strange problem: during the execution of the browser a tag script, open the B tag to access the same script, it will be pending until execution of A is complete. This script executes session_start (), while PhP session_start () excludes the write to this session. Only when the script execution ends or session_destroy () is explicitly executed () to release the session file lock. Because I don't know how the session works, I am troubled by a full workday! A similar problem is that the conversion rules of character encoding in lamp are not understood, and some texts in GBK and gb2312 are not allowed to be written into the database.

Therefore, you need to know why. It is necessary to understand the necessary knowledge before launching web development, or to turn around without a head-on fly during bug tuning. Doing well in your own construction will always be better than passively satisfying case by case.

Capture the session and cookie to be logged on to the page