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

This article will explain in detail how the session of the browser disappears. The content of the article is of high quality. Therefore, Xiaobian shares it with you as a reference. I hope that after reading this article, you will have a certain understanding of relevant knowledge.

When doing interface testing, you often encounter the type of token as the request parameter, but most testers may still have a smattering of the difference between token, cookie, and session.

Cookie

Cookies are a very specific thing, referring to a kind of data that can be stored permanently in the browser, just a data storage function implemented by the browser.

Cookies are generated by the server and sent to the browser, which saves the cookie as kv in a text file under a directory and sends the cookie to the server the next time the same website is requested. Because cookies are stored on the client, browsers impose restrictions to ensure that cookies are not used maliciously and do not take up too much disk space, so the number of cookies per domain is limited.

Session

A session is literally a conversation. This is similar to talking to someone. How do you know that Zhang San and not Li Si are currently talking to you? The other party must have some characteristics (length equality) that indicate that he is Zhang San.

Session is a similar logic, the server needs to know who is currently sending the request to itself. In order to do this distinction, the server assigns a different "identity" to each client, and then each time the client sends a request to the server, it carries this "identity", and the server knows who the request came from. As for how the client saves this "identity," there are many ways. For browser clients, everyone defaults to cookies.

The server uses session to temporarily save the user's information on the server, and the session will be destroyed after the user leaves the website. This method of storing user information is more secure than cookies, but sessions have a drawback: if the web server does Load Balancer, the session will be lost when the next operation request goes to another server.

Token

Token introduction: Token is frequently requested by the client to the server for data, and the server frequently queries the username and password in the database and compares them to determine whether the username and password are correct or not, and makes corresponding prompts. Under such background, Token comes into being.

Token definition: Token is a string of characters generated by the server as a token requested by the client. After the first login, the server generates a Token and returns it to the client. Later, the client only needs to bring this Token to request data, without having to bring the username and password again. The simplest token consists of uid(user's unique identity), time(timestamp of current time), sign(signature, compressed into a long hexadecimal string by hash algorithm from the first few digits of token + salt, which can prevent malicious third parties from splicing token request server).

The purpose of using Token: The purpose of Token is to reduce the pressure on the server, reduce frequent queries to the database, and make the server more robust.

Traditional authentication

HTTP is a stateless protocol, meaning it doesn't know who is accessing the application. Here we think of the user as a client. The client authenticates using a username and password, but the next time the client sends a request, it has to verify again.

The solution is that when the user requests to log in, if there is no problem, we generate a record on the server. This record can explain who the logged in user is, and then send the ID number of this record to the client. After receiving it, the client stores this ID number in a Cookie. The next time this user sends a request to the server, he can bring this Cookie. In this way, the server will verify the information in this Cookie. See if you can find the corresponding record here on the server. If you can, it means that the user has passed the authentication and returns the data requested by the user to the client.

We need to store the sessions generated for logged in users on the server, which may be stored in memory, disk, or database. We may need to periodically clean up expired sessions on the server side.

Token-based authentication

With Token-based authentication, there is no need to store user login records on the server. The general process is as follows:

The client requests login using username and password

Server receives request to verify username and password

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

After receiving the Token, the client can store it, such as in Cookie or Local Storage.

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

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

APP login when sending encrypted username and password to the server, the server verifies the username and password, if successful, in some way such as random generation of 32-bit string as token, stored in the server, and return token to APP, later APP request, where verification needs to take the token, and then server-side verification token, successful return of the required results, failure to return error message, let him log in again. The token on the server sets a validity period, and the token and validity period are verified every time the APP requests it.

So here's my question:

1. The token on the server is stored in the database, and each query will not be very time-consuming. If not stored in a database, where should it be stored?

2. The token obtained by the client must be encrypted and stored, and decrypted when sending the token. Is it stored in a database or a profile?

Token is volatile data, lost nothing but let the user log in again, Sina Weibo often let me log in again, anyway, I don't care about this matter.

So if you feel that ordinary database tables can't hold up, you can put them in MSSQL/MySQL's memory table (but it is said that mysql's memory table performance improvement is limited), you can put them in Memcache (to tell the truth, this is a very common strategy), you can put them in redis (I have done this), and you can even put them in OpenResty's variable dictionary (as long as you are confident that you don't explode memory).

Token is a receipt, but it is much gentler than tickets. If you lose tickets, you can buy them again. If you lose tokens, you can authenticate one again. Therefore, the cost of losing tokens is tolerable. If you don't lose them too often, you will lose the user experience if you let the user authenticate them every three or five times.

Based on this starting point, if you think that using the database to hold token queries for too long will become a bottleneck or hidden danger in your system, you can put it in memory.

Memcached, redis, and KV methods are ideal for your token query needs.

This will not take up too much memory, for example, your token is a 32-bit string, if your number of users in the millions or tens of millions, then how much memory.

If the amount of data is really large enough that the memory of a single machine cannot withstand it, or if you feel that the risk of losing all the tokens is high, as long as the token generation is uniform enough, the high and low bits can be divided into different machines, and the memory will definitely not be a problem.

On the client side, unless you have a very secure approach, such as a private data store provided by the operating system, there will definitely be a problem with the token. For example, I get your phone, copy your token, and log in as you elsewhere before it expires.

A simple solution to this problem

1. Symmetrically encrypt the token when storing it, and unlock it when storing it.

2. Combine the request URL, timestamp and token with salt signature, and verify the validity of the server.

The starting point for both approaches is that it's easier to steal your stored data than it is to disassemble your programs and hack your encryption, decryption and signature algorithms. However, in fact, it is not difficult to say that it is difficult, so it is ultimately a way to prevent gentlemen from preventing villains. In other words, encrypted storage, if you are opened by people, the client will not be sprayed with plain text storage...

Method 1 it gets the stored ciphertext solution, method 2 it does not know your signature algorithm and salt, the two can be combined to eat.

However, if token is handcuffed, he can naturally be implanted into his own mobile phone, and then his mobile phone can also be used as your identity. You will be blind.

So you can provide a similar mechanism that allows users to actively expire a past token and remotely stop losses when stolen.

Token plaintext transmission at the network level can be very dangerous, so it is recommended to use HTTPS and put the token in the post body.

Additional:

Difference between cookies and sessions

Cookie data is stored on the client, and session data is placed on the server.

2, cookies are not very safe, others can analyze the local COOKIE stored in the COOKIE and COOKIE fraud

Session should be used for security reasons.

The session will be saved on the server for a certain period of time. When the number of visits increases, it will consume the performance of your server.

Cookie should be used to mitigate server performance.

A single cookie can store no more than 4K data, and many browsers limit a site to 20 cookies.

5. Therefore, personal suggestions:

Store important information such as login information as SESSION

Other information can be stored in cookies if needed

Difference between session and token

Session and oauth token are not contradictory, as identity token security is better than session, because each request has a signature and can prevent monitoring and replay attacks, and session must rely on the link layer to ensure communication security. As mentioned above, if you need to implement stateful sessions, you can still add sessions to save some state on the server side

Apps usually use restful APIs to deal with servers. Rest is stateful, that is, apps do not need cookies to save sessions like browsers, so it is enough to use session tokens to identify themselves, and session/state is handled by the logic of api server. If your backend isn't a stateful rest api, then you may need to save sessions in your app. You can embed webkit in your app and use a hidden browser to manage cookie sessions.

Session is an HTTP storage mechanism designed to provide persistence for stateless HTTP. The so-called Session authentication simply stores User information in the Session, because SID is unpredictable, temporarily considered safe. This is a means of authentication. Token, if it refers to OAuth Token or similar mechanism, provides authentication and authorization, authentication is for users, authorization is for apps. The goal is to give an App access to a user's information. The Token here is unique. It cannot be transferred to other apps, nor can it be transferred to other users. Turn around and say Session. Session provides only a simple authentication, that is, with this SID, it is assumed that this User has all rights. This data should only be kept on the site and should not be shared with other websites or third-party apps. So simply put, if your user data may need to be shared with third parties, or allow third parties to call API interfaces, use Token. If it's always just your own website, your own App, it doesn't matter what you use.

Breaking the misunderstanding:

"Just close the browser and the session disappears." "

No, no. For sessions, unless the program notifies the server to delete a session, the server will always keep it, and the program generally sends an instruction to delete the session when the user does log off.

However, the browser never actively notifies the server that it is about to close before closing, so the server does not have a chance to know that the browser has been closed. The reason for this illusion is that most session mechanisms use session cookies to save session ids, and after closing the browser, this session id disappears, and the original session cannot be found when connecting to the server again.

If the cookie set by the server is saved on the hard disk, or some means is used to rewrite the HTTP request header issued by the browser and send the original session id to the server, the browser can still open the original session again.

It is precisely because closing the browser will not cause the session to be deleted, forcing the server to set an expiration time for the session. When the time from the last session used by the client exceeds this expiration time, the server can delete the session to save storage space for the client has stopped.

About the browser session is how to disappear to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

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.