HTTP stateless? Session Cookie Token

Source: Internet
Author: User
Tags hmac

http stateless?

An HTTP stateless protocol means that the Protocol has no memory capability for interactive scenarios.

When you click on a plain HTML page and request the HTML file resource of the server, each HTTP request will return the same information, because each request that has no interaction is independent of each other, the first request and the second request are not sequenced, and the result is the same resource page. Because this scenario is non-interactive, no matter what person requests that resource, the server is a brain that returns the same file.

But it's embarrassing to have a scene that involves dynamic interaction. What is interaction? There comes and goes, not the same as above, no matter who requests the same address is returned exactly the same response.

Now let's think of a complex scenario, such as buying a schoolbag on a shopping site, as follows:

    1. Enter account password Login/login user information
    2. Choose a schoolbag you like to add to your cart/cart user information, product information
    3. Purchase Payment/pay user information, product information, amount information

The so-called login is only to verify that you are a legitimate user, if it is legal to jump to the page of information, the law tells the user name password error.
When adding a product/cart you still need to submit your account password and product information to the Addcart interface, and then let the server do the verification.
The third step is the same.


When it comes to interaction, the situation is completely different, because the three steps are dependent, the first step is to verify that the login is a legitimate user, and verify that by returning the 200/ok to you, an HTTP request and response will be terminated as soon as the server returns a response. How did the server know that you just logged in 10 seconds ago? Sorry, the server does not know if you have logged in, he just provide a login interface, to prove that you are legitimate users must tune/login interface.

In the second step, when you add a product to your shopping cart, you call the/cart interface, but notice that this behavior is related to the first step, who is adding something to the cart? Who, is there a registered account on the website, is not a legitimate user? So when adding a shopping cart, we also need to add the account password again to the request parameters, every time you operate the shopping cart operation, you need to put the previously transmitted account password, and then repeatedly transmitted over and over again, this is because the server does not know whether you have just landed 20 seconds ago.

Summary: a lack of state means that if the previous information is required for subsequent processing, it must be re-routed, which may result in an increase in the amount of data transferred per connection. In addition, the concept of "conversation" is another way of expression of the above-mentioned interactive behavior.

The stateless state above refers to no sign-in state, that is, the server does not know if a user has logged in . Because the stupid server does not know whether the client has logged in, so each time in the interactive scene (session) request to bring the last request information, such as account number, password. Obviously only need in the/login interface, only need to compare the account password in the database and the consistency of the client pass to determine the legitimacy. This will be added in the shopping cart also need to repeat the same again and do not have the necessary actions, that is, reduce the response speed and user unfriendly (because each time the need to fill in the account, password)

Through the above we know what is stateless in HTTP is a concept, and in the stateless situation, to add the shopping cart function, the difficulties brought.

After the advent of Web applications in which clients interact dynamically with the server, HTTP stateless features seriously hinder the implementation of these applications, after all, the interaction needs to be followed, and the simple shopping cart program knows what the user has chosen before. As a result, two techniques for keeping the HTTP connection state are created, one is a cookie and the other is a session. HTTP itself is a stateless connection protocol, in order to support the interaction between the client and server, we need to use different technologies for the interactive storage state, and these different technologies are the cookie and session.

Cookies

Because HTTP is a stateless protocol, the server simply does not know the identity of the client from the network connection . What do we do? Give the client a pass, one per person, who must bring their own pass for whoever accesses it. This allows the server to confirm the identity of the client from the pass. That's how cookies work.  

A cookie is actually a small piece of text information. The client requests the server and, if the server needs to log the user state, uses response to issue a cookie to the client browser. The client browser will save the cookie. When the browser requests the site again, the browser submits the requested URL along with the cookie to the server . The server checks the cookie to identify the user state. The server can also modify the contents of the cookie as needed.

Non-cross-domain names of cookies

Many websites use cookies. For example, Google will issue Cookie,baidu to clients and also issue cookies to clients. Will the browser's access to Google also carry the cookies issued by Baidu? Or can Google change the cookie issued by Baidu?

The answer is in the negative. Cookies have non-cross-domain names. According to the cookie specification, browser access to Google only carries Google's cookies and does not carry Baidu's cookies. Google can only operate Google's cookies and not operate Baidu's cookies.

Cookies are managed by the browser on the client side. The browser can guarantee that Google will only operate Google's cookies without manipulating Baidu's cookies, thereby ensuring the privacy of the user. The browser determines whether a Web site can manipulate another site cookie based on the domain name. Google does not have the same domain name as Baidu, so Google cannot manipulate Baidu's cookies.

An example of a cookie1. When logging into the website, select Remember Password

2. Click on the server to see the corresponding content

3. View the cookie settings in Chrome

4. Observe the cookie content returned by the server

5. Re-visit, found that no need to enter a password to log in directly to observe the request header information

three scenarios where a cookie records the status of a login

Cookies are not purely for the purpose of implementing the session mechanism. Instead, in 1993, Netscape employee Lou Montulli invented the widely used Cookie today in order to make it possible for users to access a website more quickly and to further implement a personalized network. Cookies also use a very broad purpose is to remember the user's login account and password, so that when users need to log on to the same site or system again, it is not necessary to fill in the two fields again, but directly click the "Login" button. This is equivalent to giving some "sweetness" to the user, which responds to the literal meaning of the word "cookie".

If the user is in their own home computer online, log in can remember his login information, the next time you visit do not need to log in, direct access.

The way to do this is to keep the login information such as account number, password, etc. in the cookie, and control the validity of the cookie, and then verify the login information in the cookie on the next visit.

There are several scenarios for saving login information

    • Scenario One: The most straightforward is to keep the user name and password in the cookie, the next visit to check the cookie user name and password, compared with the database. This is a more dangerous option and generally does not store important information such as passwords in cookies.

    • Scenario Two: The password is encrypted and saved to the cookie, the next time the visit is decrypted and compared with the database. This scheme is slightly safer. If you do not want to save the password, you can also save the time stamp of the login to the cookie and the database, only to verify the user name and logon timestamp.

    • Scenario Three: The database is queried only once at logon, and the database is no longer queried for subsequent access to the authentication login information. The way to do this is to encrypt the account according to certain rules, and save it to the cookie together with the account number. The next time you visit, you only need to determine whether the encryption rules are correct.

One and 22 scenarios to verify the account when the database is queried.

Program three save the account to the cookie named account, and then use the MD5 algorithm to encrypt the accounts together with the key to save to the cookie named SSID. Verify that the account and key in the cookie are encrypted with the same SSID as the cookie.

Tip: The most important part of this encryption mechanism is the algorithm and key. Because of the irreversibility of the MD5 algorithm, even if the user knows the account and the encrypted string, it is impossible to decrypt the key. Therefore, the mechanism is safe as long as the key and algorithm are kept.

Session

Because a Web page is a stateless connection program, you cannot know the user's browsing status. When you shop online, you add a lot of items to your shopping cart, and when you checkout, you don't know what your shopping cart has. To solve this problem, the server creates a specific session for a specific user to mark and track the user so that they know what is in the cart.

    • The session is another mechanism for recording the state of a customer, but the cookie is stored in the client browser and the session is stored on the server.

    • When the client browser accesses the server, the server logs the client information to the server in some way. This is the session. When the client browser accesses it again, it only needs to find the customer's status from that session.

    • If the cookie mechanism is to determine the customer's identity by checking the "pass" on the client, then the session mechanism verifies the customer's identity by checking the "customer schedule" on the server.

    • Session is equivalent to a program on the server set up a customer profile, when customers visit only need to query the customer file table on it.

the relationship between session and Cookie
      • A cookie is an actual, specific thing that is defined in the Header field in the HTTP protocol.
      • The session is an abstract concept in which the developer, in order to implement interrupts and continuation operations, abstracts the one-to-one interaction between the client and server into a "session", thus deriving the "conversational state", which is the concept of sessions.
      • The session describes a communication session mechanism, and a cookie is only a participant in the current mainstream scheme that implements this mechanism, which is typically used to hold session IDs.
 See http://weixin.niurenqushi.com/article/2017-03-20/4794863.html for token related explanationsHMAC Description: HMACReference article:HTTPS://WWW.JIANSHU.COM/P/BDC97C096FBChttps://www.cnblogs.com/bellkosmos/p/5237146.htmlhttp://weixin.niurenqushi.com/article/2017-03-20/4794863.htmlhttps://www.cnblogs.com/yupeng/archive/2012/05/24/2515228.html

HTTP stateless? Session Cookie Token

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.