Session/Cookie handling bug in soapUI 4.5.1

[jsoderstrom]

I'm trying to upgrade to soapUI 4.5.1 but I'm running in to problems concerning the handling of Cookies. All test cases use the "Maintain HTTP session" setting since we rely in part on using the JSESSIONID cookie. In 4.0.1, each test case would get a new session without any cookies. In 4.5.1 however, the same session seems to be maintained across all test cases. Say I have two test cases, A and B. After running A, the first request sent by B will contain any cookies set by A.

I can get rid of this issue by clearing out any cookies in the setup script of each test case, but that's a lot to maintain when you have hundreds of test cases.

[SmartBear Support]

Hi,

Are you sure that this is soapUI 4.5.1, and not 4.5.0? This was a known bug in 4.5.0, but should have been fixed in 4.5.1 (I just verified this by running this issue's unit test).

Regards

Henrik
SmartBear Software

[jsoderstrom]

Could you point me to the issue that you mentioned? I'm not really sure this is the same issue.

I am certain that I get this problem in 4.5.1. To verify it, I run two tests in a row and then look at the Raw request information of a step in each of the test cases. I can then see that they both send the same JSESSIONID (for example Cookie: JSESSIONID=C2434FF9BE1FF8B2AB7A34836F456879.@JVM_ROUTE@) to the server. Using 4.0.1, each test case would start a fresh session. In 4.5.0, the Raw view doesn't show all headers sent, so I can't determine the behavior using this approach.

[bosma4u]

I observed also HTTP session is no longer properly maintained in recent versions of soapUI. I tested with 4.5.1 and the latest nightly build, all with the same results.
There seems to be one HTTP session shared by all threads. I created a testcase (attachment) to demonstrate this behavior. I checked "Maintain HTTPS Session".
I created a webservice that creates a session. Subsequent calls report the number of times this particular session
has been used. This public service is (temporary) available at http://d4cca2c7.cm-2.dynamic.ziggo.nl:8 ... ount_calls.

If you call it in a browser the behavior can be checked by using <F5>.

I call this service twice in the testcase: the first time the times_uses should be 0, the second time is should be 1. The single testcase is successful, but the loadtest with multiple threads fails big time! The same session cookie is used for all calls by all threads. A small improvement can be made by dropping the cookie in the first test step, but I don't think that should be necessary.

[rsisto]

Hi, could you post the setup script to clear the cookies? I'm having the same issue.
Thanks in advance.

EDIT - Never mind, I found the code inside your test case

[ftrftr]

This issue was already posted here (4.5.0):
viewtopic.php?t=13382

[SmartBear Support]

Hi!

This issue has been resolved in the latest nightly build of soapUI Pro.
Please download it from here: http://www.soapui.org/Downloads/soapui- ... uilds.html

Hope this helps!

--
Regards

Erik
SmartBear Sweden

[PiRanha]

Hello,

Is the fix planned for the non-pro version of SoapUI ? When can we hope such a fix ?

Additional question:
jsoderstrom talked about 2 different tests cases A and B sharing the same cookies. What about a unique test case A executed several times in parallel (load test) ?
Imagine a test case A with the following steps:
- Step 1 : get a page P1 (returning a cookie C)
- Step 2 : get a page P2 (sending the cookie C to retrieve the page properly)
Now, imagine the test case A is run twice in parallel (let's name the 2 instances A1 and A2) and the following sequence of actions is done:
a) A1 : step 1 >> value of cookie C = C1
b) A2 : step 1 >> value of cookie C = C2
c) A1 : step 2
d) A2 : step 2
Which cookie value will be sent in c) ? Will we have C1 (the expected value) or C2 (which corresponds to the last value retrieved by an instance of the test case, but is not the correct value) ?
In other words, with the fix mentioned by Erik, will each instance of a same test case have its own cookies or not ? (especially in case or parallel execution)

Thanks in advance.
Regards.

[mannyvel]

Note that in 4.5.1, cookie information is occasionally not sent. Here are the headers from one login attempt:

Request
-------
POST /MYAPP/j_spring_security_check?j_username=testuser1&j_password=testpassword&submit=login HTTP/1.1
Accept-Encoding gzip,deflate
Content-Type application/xml
Content-Length 0
Host 54.236.95.134:8085
User-Agent Apache-HttpClient/4.1.1 (java 1.5)
Response
--------
HTTP/1.1 302 Found
Set-Cookie: JSESSIONID=E85FAE1859332A53F04E6B254B728219; Path=/MYAPP
Location: http://MYIP:MY_PORT/MYAPP/;jsessionid=E ... 254B728219
Content-Length: 0
Date: Tue, 16 Apr 2013 18:51:55 GMT
Server: MY Server

Request
-------
POST /MYAPP/messagebroker/amf HTTP/1.1
Content-Length 80
Host MYIP:MYPORT
User-Agent Apache-HttpClient/4.1.1 (java 1.5)

The request should look like this (from a successful server interaction):

POST /MYAPP/messagebroker/amf HTTP/1.1
Content-Length: 80
Host: MYIP:MYPORT
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JSESSIONID=DBCE025C4B47D9B8402FF2857585405F
Cookie2: $Version=1

This only happens when running > 1 client. I downloaded the latest soapui nightly build (16 apr 2013), and cookie functionality is totally broken. This is sort of basic - how solid is the cookie/session handling in the Pro version?

[bjhoops1]

I have been experiencing this same issue as described by mannyvel. I had a perfectly working test two days ago, which maintained session through Cookie: JSESSIONID=XXXXX, but today, presumably after the latest nightly build, it is no longer adding the JSESSIONID cookie http header to subsequent requests.

Is there a way for me to roll back to an earlier build? And are there any plans to fix this? I have an important project pending in the next couple of days and would really hate to have to resort to manual groovy scripting.

Thank you.l

[sirood]

I experience the same issue

Regards, Simon

[mannyvel]

This also happens in LoadUI, which apparently uses SoapUI underneath.

The good thing is that you can check for this by saving off the JSESSIONID value in the context after you get a session, then using a script between each step to compare the value of JSESSIONID to your stored value. If it doesn't match, you can try and force JSESSIONID back to the old one or just jump to your logout handler, or both.

This isn't ideal, but it mostly works.

I'm curious if this happens in the Pro version. Are there people who paid $10k for a tool (load ui pro) that can't handle sessions correctly?

[mannyvel]

As a note, checking for the JSESSIONID by hand doesn't work. Next thing I'm going to try is turning off session support and just using cookies directly.

[mannyvel]

Just verified that the same bug occurs in SoapUI Pro 4.5.1.

This is a simple testcase with 4 calls:

login/http
login/amf
search/amf
logout/http

There are two threads in the loadtest, with 1 run per thread.

This is what I see (from the Charles proxy). The second cookie is never used. I see from psiprobe that that other session is an anonymous session, hanging out on the server waiting to expire.

Request
POST /MY_APP/j_spring_security_check?j_username=testuser1&j_password=testpassword&submit=login HTTP/1.1
Response 1
Set-Cookie JSESSIONID=7E2EF24479D172EE9AE066D75B5F3AAC; Path=/MY_APP
Request 2
POST /MY_APP/j_spring_security_check?j_username=testuser2&j_password=testpassword&submit=login HTTP/1.1
Response 2
Set-Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD; Path=/MY_APP
Request 3
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 4
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 5
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 6
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 7
GET /MY_APP/j_spring_security_logout HTTP/1.1
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 8
GET /MY_APP/j_spring_security_logout HTTP/1.1
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD

I noticed that the user-agent is:

User-Agent Apache-HttpClient/4.1.1 (java 1.5)

My local java is:

java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)

[mannyvel]

Since sessions work fine when you run only test at a time, you can bypass the session bug by spawning multiple testrunners from a driver shell script and parameterizing in the script.

You won't get the fancy graphs, but you can log the data and use excel, etc to make graphs.

I haven't heard anything definitive, but apparently sessions aren't supported in load tests, even in the pro version.