Get POST distinguish similarities and differences
Taobao token understand the process algorithms to prevent forgery request forgery is relatively difficult
Simple history of
Login operation : who to put in their shopping cart of goods, means that I must separate area for everyone, this is not a small challenge, because the HTTP request is stateless, so come up with ways is to give everyone send a session identifier (session id), it means a random string that is different for each person received, each time you initiate to me when HTTP requests, this string to take along came together, so that I will be able to distinguish who is who
So it is very Hi skin, but the server is not leather Hey, everyone just needs to keep the session id, session id and the server you want to save everyone! If access to the server and more, and have made hundreds of thousands, even hundreds of thousands.
This is said to be a huge server overhead , severely limits the scalability of the server, for example, I use two machines form a cluster, small F through A machine logged into the system, it will save the session id on the machine A, assuming that F is a small request is forwarded to the machine B how to do? Session id machine B may not small F ah.
Sometimes uses a little trick: the session Sticky, is to make a small request F has been sticking on the machine A, but this is not effective, and if the machine A hang, had to go to the machine B to go.
It had to do copy of the session, the session id moved around between two machines quickly exhausted.
Later, a man named Memcached support of a trick: the session id stored centrally in one place, all the machines are used to access the data of this place, this way, they do not copy, but it increases the likelihood of a single point of failure, if that session is responsible for the machine hung up, everyone had to log in again and again, it is estimated Masi people.
So some people have been thinking about, why I want to save this nasty session it, just let each client to preserve nice?
But if you do not save the session id, how to verify a client's session id sent to me indeed is my generation do? If you do not verify, we do not know that they are a legitimate user is not logged on, those guys can forge malicious session id, do whatever they want.
Ah, yes, the key point is to verify ! ================================================== =================
===================================================================
For example, a small F has logged into the system, I sent him a token (token), which contains a proposed user id small F, the next time I visit small F again through Http request, when this token via Http header with not over it.
But this and session id is no essential difference ah, anyone can be forged, so I have to do something about, so that others can not fake.
Then the data to make it a signature, for example, I use the algorithm HMAC-SHA256, a plus only I know the key, the data make a signature, the signature and the data together as a token, because the others do not know the key , the token can not be forged.
This token I do not save, when this small token to F me over when I use the same HMAC-SHA256 algorithm and the same key, the data re-calculated once the signature, and the signature token make a comparison, If so, I know that a small F has logged over, and can be taken directly to the user id small F, if not identical, the data portion certainly been tampered with, I'll tell the sender: Sorry, no certification.
Of course, if a person's token is stolen someone else, then I have no idea, I would think the thief is a legitimate user, and this is actually a person's session id was stolen someone else is the same.
As a result, I will not save the session id, I just generate token, then verify that token, I use my CPU time to obtain my session storage space!
The lifting of the session id of this burden can be said that nothing out of danger, my machine clusters can now easily do horizontal scaling, user traffic increases, plus the machine directly on the line. This stateless feeling is wonderful!
Cookie
A cookie is a very specific thing, A data refers to the browser which can be permanently stored, is merely a data storage function of the browser implementation.
cookie generated by the server, sent to the browser, the browser cookie saved to a text file in a directory to kv form, will send a cookie to the server the next time you request the same site. Since the cookie exists on the client, the browser adds some restrictions to ensure the cookie will not be used maliciously, but will not take up too much disk space, so the number of cookie per domain is limited.
Session
Literally session is a session. This is similar to you and talk to a person, how do you know you talk to current and Joe Smith, not John Doe is it? There must be some other characteristics (appearance, etc.) that he is Joe Smith.
session is a similar reason, the current server you want to know who made the request to his yes. In order to make this distinction, going to a different server for each client is assigned "identity", and then sent to the server each time the client requests the time, are put on the "identity", the server knows that the request comes from who had. As for the client how to save this "identity" can have a variety of ways, for browser clients, we are using the default cookie manner.
The server uses session to the user's information is temporarily saved on the server, user session after leaving the site will be destroyed. This user information is stored relatively cookie is more secure, but the session has a flaw: If the web server to do load balancing, then the next operation request to another server when the session will be lost.
Token
In the field of Web-based validation everywhere Token identity. In most use Web API Internet companies, tokens is the best way to handle multi-user authentication.
The following properties will let you use in your program based Token Authentication
1. stateless, scalable
2. support for mobile devices
3. Cross-program calls
4. Security
Token principle of verification
Based Authentication Token is stateless, we will not exist in the user information server or Session.
This concept solves many of the problems of information stored on the server
NoSession means you can program the machine to increase or decrease as needed, without having to worry about whether the user is logged in.
Based Token authentication process is as follows:
1. The client sends a request via a user name and password.
2. Verify program.
3. The program returns a signed token to the client.
4. The storage client token, each time for each transmission request.
The authentication token and the server returns the data.
Each request requires token. token in the HTTP header to be transmitted to ensure the Http request stateless. We also by setting server properties Access-Control-Allow-Origin: *, so that the server can receive requests from all domains. The main need is indicated (designating) * When in ACAO head, not like with HTTP authentication, SSL certificates and client certificates of cookies end.
1. The user logs check, check after the success Token returned to the client.
2. The client after receiving the data stored in the client
3. Client API each visit is carrying Token to the server.
4. The server uses the filter calibration filter. The requested data is returned check is successful, it returns an error code check fails
When we authentication information and get in the program after token, we will be able to do many things through this Token.
We can even create a based on rights to a third party application token, these third-party programs can obtain our data (of course, only in a specific token we allow)
===================================================================
Tokens advantage
Stateless, scalable
Client stored Tokens are stateless, and can be extended. Based on this storage state and a non-Session information, the load balancer is able to load user information from a service transmitted on another server.
===================================================================
safety
Sending the request token is no longer possible to prevent the transmission cookie CSRF (cross-site request forgery). Even if the client uses a cookie to store token, cookie store is only a mechanism and not for certification. The information is not stored in the Session, so that we have less of session operation.
===================================================================
Scalability ()
Tokens can create programs to share authority with other programs. For example, can a casual social accounts and its own large (Fackbook or Twitter) link. When you log in Twitter (we will this process Buffer) through the service, we can use these Buffer attached to the Twitter data stream (we are allowing Buffer to post to our Twitter stream).
===================================================================
Multi-platform cross-domain
We advance the first to talk about CORS (cross-domain resource sharing), when applications and services expanded, the intervention of all kinds all kinds of devices and applications.
===================================================================
Based on standard
Create a token, you can set some options. We will be more fully described in a future article, but the standard usage Tokens will be reflected in the JSON Web.