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

Following the previous article, I introduced two common uses of Jmeter cookie manager:

Jmeter video: https://edu.51cto.com/course/14305.html

Passing cookie between the same thread group and different thread groups

A few days ago, I encountered the problem of cross-domain use of cookie in my work. I debugged it for a long time and checked a lot of information, from the implementation principle of cookie to SSO single sign-on to SSO implementation, then to session, token, to OAuth authentication.

Originally, I wanted to write a detailed article to talk about the whole context of this piece of knowledge, but after several revisions, I found that I could not describe every detail clearly, so I was entangled for a long time, and the revision was still not completed.

After reflection, I am too greedy and pursue perfection. I want to finish a large number of knowledge points in an article, but I have not reserved enough knowledge, even if I can write a long article. I believe everyone does not want to read a stinky article, so everything should be done slowly, one step at a time, step by step.

Therefore, today, let's start with the initial problems, and then gradually improve and expand.

First, the background of cookie cross-domain problems

The problem is that in the previous article, I mentioned passing cookie across thread groups by:

Call the setProperty and getProperty methods in the JMeterUtils class

Save the cookie in the global variable in the thread group that generated the cookie

Then take out the value of the global variable in another thread group that needs to use cookie

Thus, the cross-thread group transmission of cookie is realized.

But

Is a cross-thread group cross-domain?

What exactly is cross-domain delivery?

How to achieve cross-domain delivery of cookie?

In fact, the implementation method is similar to the previous article, but some details involve many aspects, which is very easy to step on.

II. Cookie mechanism

First, we need to take a closer look at the cookie mechanism.

The main purpose of Cookie mechanism is to make up for the deficiency of stateless feature of HTTP protocol.

1. Characteristics of HTTP protocol

At present, most Web applications are based on HTTP (Hypertext transfer Protocol), which is characterized by simple, fast, flexible, connectionless and stateless.

Stateless means that the http protocol has no memory ability for transactions. After the data exchange is completed, the link between the server and the client will be closed, and a new link needs to be established every time the data is exchanged.

This means that if the previous information is required for subsequent processing, it must be retransmitted, which may result in an increase in the amount of data transmitted per connection, but it responds faster if the server does not need the previous information.

But in many cases we want to use the previously requested data, such as you log in to the mailbox and log on to a page, and we often set me within 30 days, or automatic login options. so how do you record the information in this case?

Is to use cookie to save!

Cookie is set by the HTTP server, saved in the browser, and is the solution to keep the state on the client side.

2. Classification of Cookie

Cookie is divided into session cookie and persistent cookie.

Session cookie: refers to the state when its life cycle expires is not set.

The browser is a session from opening to closing, and when the browser is closed, the session cookie is destroyed with the browser (when a page is closed, the session cookie is not affected). Conversation cookie is like going shopping without a membership card. It is a single buying and selling process. After leaving, the information is destroyed.

Persistent cookie: its life cycle expires is set. At this time, cookie, like a commodity, has an expiration date. After closing the browser, it will not be destroyed until the set expiration time.

For persistent cookie, you can transfer data in the same browser. For example, after you open a Taobao page and log in, you click on a product page and still log in status. Even if you close the browser and open it again, it will still be login status. This is because cookie automatically transmits the data to the server and gives it back. Persistent cookie is like when we apply for a membership card, even if we leave, the information is kept until the time expires and the information is destroyed.

3. The security of Cookie

The data in Cookie usually contains the user's private data, so in order to ensure the confidentiality of the data, it is usually necessary to encrypt the cookie content.

Encryption generally uses symmetric encryption (single key, such as DES) or asymmetric encryption (a pair of keys, such as RSA), and the key needs to be stored in a secure place on the server side.

4. Attributes of Cookie

Cookie is composed of name, content, action path Path, scope Domain, protocol, expiration time expires, secure (representing security level), HttpOnly and other attributes.

It is typically set in the response header of the web server, similar to the following:

After the server returns the cookie to the client, it is usually saved in the browser as a string.

The interaction process is shown in the following figure:

When the browser visits the page 1, the web server sets up a cookie and returns the cookie to the browser together with page 1. After the browser receives the cookie, the browser will save it, and when it visits page 2, it will also bring the cookie. When the Web server receives the request, it can also read the cookie value, and the information status of some users can be judged and restored according to the content of the cookie value.

5. Scope of Cookie (domain)

1) if the domain attribute of Cookie is not set, it is the domain name of the current request by default

2) when the Cookie scope is a parent domain name, all child domain names can get the cookie

For example, there are now two domain names, web1.test.com,web2.test.com, which have a common parent domain test.com, and if the domain property of cookie is set to test.com, then both web1.test.com and web2.test.com can access the cookie.

At this time, some friends may think that if I set the cookie scope to the top-level domain name (.com, .net), can all the websites of the top-level domain name get the cookie?

Haha, if the cookie is set in this way, the browser will not store it and it will not be valid.

3) cookie cannot be accessed across second-level domain names

For example, if the domain property of cookie is set to web1.test.com, then web2.test.com cannot access the cookie.

Therefore, cookie cannot be accessed directly across domain names!

Third, the concrete realization of cookie cross-domain transmission.

Since cookie cannot be accessed directly across domain names

Then why did you talk about cookie cross-domain access?

In fact, we often hear that cookie cross-domain name access is not direct access, all need to go through intermediate processing.

For example, save the cookie of web1, and then take it out of web2 and use it.

Another example is to let two different domain names, web1.com and web2.com, use a common authentication system to keep public cookie information in the same authentication system, which is currently used by www.taobao.com and Tmall.

For example.

So how to implement cookie cross-domain access in jmeter?

The general idea is to use the first method just mentioned: "save the cookie of web1 and then take it out of web2 and use it."

4. Business scenarios:

Query user information after login

You need to get the cookie in the login thread group and save it

Then take out the cookie in the query user information thread group and send the request with cookie.

Implementation steps:

1. Add a cookie manager to the login thread group to make jmeter save cookie information automatically.

Then execute the script and look at the cookies in the response headers of the login request in the result tree. Here I'll just take one of the cookie named token as an example.

Note: the domain of the cookie generated here is xxxx.com, so do you want to set it to the same domain later? Look down first.

2. Add a beanshell post processor to the login thread group, and add the following script to it:

SetProperty (proname,provalue):

This method saves a string in a global variable (the scope of the global variable is the entire test plan), where the first parameter is the name of the global variable and the second parameter is the value of the global variable.

When there are multiple cookie values, you can write a multiline setProperty method, taking only one cookie as an example.

3. Add a cookie manager and a beanshell pre-processor to another thread group that needs to use cookie, and set them as follows:

GetProperty ("proname"):

This method gets the value of the global variable with the specified name, where the parameter is the name of the global variable

Vars.put ("proname", "provalue"):

This method stores the specified string in a local variable (scope is the current thread group), with the first parameter being the name of the variable and the second parameter being the value of the variable.

The log.info () method is a log printed to assist debugging scripts.

Let's look at the settings of cookie manager:

Implementaion: refers to the implementation of cookie. Jmeter3.0 starts with HC4CookieHandler by default.

Cookie Policy:cookie policy, starting from jmeter3.0, defaults to standard, which is specifically related to the server-side implementation, which may vary from company to company. I have tried several other options and can not get cookie, only netscape can get it. So when you have trouble getting cookie, you can also check this option.

Cookie stored in the cookie manager: user-defined cookie can be added here and will be shared by all threads in the scope.

The name here is the same as the name of cookie we saw earlier in the result tree, and the value is the value we just saved in the local variable.

The value of the domain in it should be the same as the domain name in the current thread group, but not necessarily the same as the domain of the previously saved cookie. My thread group uses IP, so if you do not enter the domain name here, it will default to the current IP, but it is wrong to enter the domain value.

So if you do not know how to fill in the domain and path here, you can just leave it empty, and jmeter will be set under the currently requested domain name by default.

The cross-domain mentioned earlier, in fact, the key point lies in the setting of the domain value here.

If it is set to the same field value as the cookie generated earlier, then it is only across thread groups, not across domains

If the domain value here is set to different from the domain value that generated cookie earlier, then it is cross-thread group and cross-domain.

Security: if it is a http request, do not check it here; if it is a https request, check it.

All right, now that the script is set up, execute the script, and you can see that cookie can be passed across thread groups and domains in the result tree.

5. Other cross-domain implementation methods

Other implementations:

The above method of manually adding cookie to cookie manager via global variables is relatively the easiest, but there are other methods, such as:

1. Save the cookie in a file instead of in a global variable:

Also write a script in beanshell, save it to a file, and then read the file.

2. Add cookie to cookie manager manually in beanshell instead of by configuring components:

A script similar to the following:

You can choose which method to use according to your needs.

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.