Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the three technologies that must be mastered in Web development". In daily operation, I believe many people have doubts about what the three technologies that must be mastered in Web development are. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "what are the three technologies that must be mastered in Web development?" Next, please follow the editor to study!

In Web applications, HTTP requests are stateless. That is, after the user initiates the request for the first time, establishes a connection with the server and logs in successfully, in order to avoid needing to log in every time a page is opened, cookie,Session appears.

Cookie

Cookie is a mechanism for the client to save user information, which is used to record some user information, and it is also a way to implement Session. The amount of data stored by Cookie is limited and is stored in client browsers. Different browsers have different storage sizes, but generally do not exceed 4KB. So using Cookie can actually store only a small piece of text information.

For example: log in to the website, enter the user name and password to log in today, and then open it the next day in many cases. One of the mechanisms used at this time is Cookie.

Session

Session is another mechanism for recording customer status. It is a data structure saved on the server (mainly stored SessionID and Session content, but also contains a lot of custom content, such as: user basic information, permission information, user organization information, fixed variables, etc.). This data can be saved in clusters, databases, files, and used to track the status of users.

When the client browser accesses the server, the server records the client information on the server in some form. This is Session. When the client browser visits again, you only need to find the status of the customer from the Session.

After the user logs in for the first time, the browser sends the user information to the server, which creates a SessionId for the user and returns the SessionId to the browser in the response content (Cookie), which saves the data locally. When the user sends the request again, the browser will automatically bring the Cookie data stored in the last request to the server automatically.

After receiving the request information, the server determines which user is the current user by the SessionId in the data requested by the browser, and then returns the user's Session data to the browser according to the SessionId in the Session library.

For example: shopping cart, after adding goods, the client side can know which items have been added, and the server side how to distinguish, so also need to store some information to use the Session.

If the Cookie mechanism determines the customer's identity by checking the "pass" on the customer, then the Session mechanism confirms the customer's identity by checking the "customer list" on the server. Session is equivalent to a customer file created by the program on the server, and customers only need to query the customer file table when they visit.

After the Session is generated, the server updates the last access time of the Session and maintains the Session as long as the user continues to access it. To prevent memory overflow, the server removes Session from memory that has not been active for a long time. This time is the timeout of Session. If you do not access the server after the timeout, Session will automatically fail.

Token

HTTP requests are all docked statelessly. That is, the HTTP server does not know whether this request is related to the last request. So there is the introduction of Session, that is, both the server and the client save a piece of text, and the client takes it with it every time it initiates a request, so that the server knows whether the client has made a request.

In this way, the client frequently sends request data to the server, and the server frequently goes to the database to query the user name and password and compare them to judge whether the user name and password are correct or not. The storage of Session needs space, and frequent query of the database causes great pressure on the server.

In this case, the Token application comes into being.

Token is a string generated by the server as a token for the client to request. When the client visits the server for the first time, the server will use some algorithms and add a key to generate a Token according to the unique ID userId passed over, and then return the Token to the client after it is encoded by BASE64, and the client will save the Token (which can be saved locally in the form of a database or file). The next request, the client only needs to bring Token, and when the server receives the request, it will use the same algorithm and key to verify the Token.

The simplest Token consists of: uid (unique identity of the user), time (timestamp of the current time), sign (signature, which is compressed into a certain length of hexadecimal string by the first few bits of Token + salt with a hashing algorithm, which can prevent malicious third parties from splicing the Token request server.

Using the Token-based authentication method, there is no need to store the user's login record on the server side. The general process goes like this:

The client requests login with a user name and password

The server receives a request to verify the user name and password

After the verification is successful, the server will issue a Token and send the Token to the client

After receiving the Token, the client can store it, such as in Cookie or database

Each time the client requests resources from the server, it needs to bring the Token signed by the server.

The server receives the request, and then verifies the Token in the client request. If the verification is successful, it returns the requested data to the client.

When APP logs in, the encrypted user name and password are sent to the server, and the server verifies the user name and password. If it is successful, it randomly generates a 32-bit string as Token, stores it in the server, and returns Token to APP. When the APP request is made later, the Token should be brought wherever verification is needed. Then the server verifies the Token and returns the required result successfully. Failure returns an error message. Get him to log back in.

For the same APP and the same phone, there is currently only one Token; phone APP that stores a currently valid Token. Token on the server sets a validity period, and each APP request verifies the Token and the validity period.

At this point, the study on "what are the three technologies that must be mastered in Web development" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.