Session
The Chinese translation of the session is "conversation", and when a user opens a Web application, it generates a time with the Web server. The server uses session to temporarily save the user's information on the server, the user leaves the site after the session will be destroyed. This type of user information storage is more secure than cookies, but session has a flaw: if the Web server does load balancing, the next operation will be lost when it requests another server.
Cookies
Cookies are data that is saved at the local terminal. Cookies are generated by the server, sent to the browser, and the browser saves the cookie in KV to a text file in a directory and sends the cookie to the server the next time the same site is requested. Because cookies exist on the client side, the browser adds some restrictions to ensure that cookies are not used maliciously and do not occupy too much disk space, so the number of cookies per domain is limited.
The composition of the cookie is: Name (key), value (value), valid domain (domain), path (the path to the field, generally set to global: "\"), Expiration Time, security flag (specified, the cookie is sent to the server (HTTPS) only when using an SSL connection). Here is a simple example of JS using cookies:
Cookies are generated when a user logs on:
Document.cookie = "id=" +result.data[' id ']+ '; path=/";
Document.cookie = "Name=" +result.data[' name ']+ '; path=/";
Document.cookie = "avatar=" +result.data[' Avatar ']+ '; path=/";
When you use the cookie, you do the following parsing:
var cookie = Document.cookie;var Cookiearr = Cookie.split (";"); var user_info = {};for (var i = 0; i < cookiearr.length; i++) {
User_info[cookiearr[i].split ("=") [0]] = cookiearr[i].split ("=") [1];
}
$ (' #user_name '). Text (user_info[' name '));
$ (' #user_avatar '). attr ("src", user_info[' Avatar '));
$ (' #user_id '). Val (user_info[' id '));
token
Token means "token", is the user authentication method, the simplest token composition: UID (user unique identity), time (timestamp of the current time), sign (signature, by the token of the first few + salt in the hash algorithm compressed into a certain length of hexadecimal strings, Can prevent malicious third party stitching token request server). You can also put the invariant parameters into the token, avoid multiple Chaku cookies and Session differences
1, the cookie data stored in the customer's browser, session data on the server.
2, cookies are not very safe, others can analyze stored in the local cookies and cookie spoofing
Consider that security should use session.
3, session will be stored in a certain period of time on the server. When the visit increases, it will take up the performance of your server
Consider the use of cookies for mitigating server performance.
4, a single cookie can not save more than 4K of data, many browsers limit a site to save up to 20 cookies.
5, so personal recommendations:
Storing important information such as login information as session
Other information if you need to keep it, you can put it in a cookie token and session difference
Session and OAuth token not contradictory, as the identity of the token security than the session, because each request has a signature can also prevent monitoring and replay attacks, and the session must rely on the link layer to ensure communication security. As mentioned above, if you need to implement stateful sessions, you can still increase the session to save some state on the server side
Apps typically use the RESTful API to deal with servers. Rest is stateless, that is, apps don't need cookies to save the session like browser, so it's enough to mark yourself with session token, session/state by the logic of the API server. If your backend is not a stateless rest API, then you may need to save the session in the app. You can embed WebKit in the app and manage cookie sessions with a hidden browser.
Session is an HTTP storage mechanism designed to provide a persistent mechanism for stateless HTTP. The so-called session certification is simply to store the user information into the session, because the unpredictability of the SID, for the moment is considered safe. This is a means of authentication. and Token, if referring to the OAuth Token or similar mechanism, provides authentication and authorization, authentication is for users, authorization is for app. The goal is to give an app a right to access information about a user. The token here is the only one. It cannot be transferred to other apps, nor can it be transferred to other users. Turn around and say session. Session only provides a simple authentication, that is, there is this SID, that is, the full rights of this user. Is strictly confidential, this data should only exist on the station side, should not be shared to other sites or third-party apps. So simply, if your user data might need to be shared with a third party, or allow a third party to invoke API interfaces, use Token. If you are always your own site, your App, it doesn't matter what you do with it.
Token is a token, for example, when you authorize (login) a program, he is a basis to determine whether you have authorized the software, cookies are written in the client's TXT file, which includes your login information and so on, so that the next time you log on to a website, Automatically invokes the cookie to automatically log in to the username; the session is similar to the cookie, except that the session is written on the server side of the file, and the cookie file is written to the client, but your browser number is in the file. The state of the session is stored on the server side, the client has only the session ID, and the token state is stored on the client.