Using Gatling with Websphere 7 - Authentication problems

Gatling (Open-Source)
1

Hi everyone !

I discovered Gatling recently, and since I have to setup some not-that-clearly-defined performance tests for my current project, I thought I’d give it a try…
I’m more a coder than a tester, so between Gatling-coding and JMeter-massclicking, the choice is quite simple. =D

But after one day struggling with it, I still haven’t manage to properly login on the application.
The login itself seems to happen properly, Gatling retrieve JSESSIONID and LtpaToken2 as expected, but then Websphere acts as if the current user is not logged at all.

Has anyone already tried and succeeded in running Gatling against Websphere ?
I’m far from being a network nor a security expert, so I probably made some newbie mistakes…

Here’s my script and execution logs (damn, can’t attach to mail !)
http://tsukilulu.free.fr/gatling/

And here’s my configuration :
Gatling 1.3.4 running inside Eclipse Juno
Websphere Application Server 7.0.0.15 - Struts2/EJB3 application, using a custom framework relying on websphere authentication.
JDK 1.6
Windows7 64bits
everything running on the same computer

I’m kind of swamped here, so if anyone has any solution or advice on how to proceed to make it works,
thanks in advance !

Josselin.

2

Hi Pierre,

Could you also print the responses (just like with requestInfoExtractor), please?
Or even better, could you record the http traffic with a tool such as CharlesProxy or tcpmon (the one produced with Gatling, and the one with a brower)?

Cheers,

Stéphane

3

Hi,

I knew I should have recorded it when I checked that…
Anyway, I’ll send you a record of the http traffic on monday ; I unfortunately can’t access work servers from home.

Have a nice weekend and thanks in advance
Cheers,
Josselin

4

Thanks and you too.

5

Hi,

As promised, here are the Charles recording / improved console output
http://tsukilulu.free.fr/gatling/20121105/

As far as I can tell, the differences start after the call to j_security_check ; the headers of the following call are quite different ; but since it appears to be a redirect i’m not sure I have much control over it.
But once again, I’m far from being a web expert, so no idea what could be the impact of such differences.

Thanks in advance for any help you could provide,

Josselin.

6

Hi Josselin,

Your scenario starts with :

.exec(http(“displayLoginPage”)
.get("/emcmn-portail/LoginServlet")
.headers(headers_1))

If I’m correct, for an authentication, you should actually not start at the login page, so, could you change your scenario so that it starts with :

.exec(http(“Restricted access page”)
.get("/emcmn-portail/")
.headers(headers_1))

Gatling should then be automatically redirected to /emcmn-portail/LoginServlet and then, you should be allowed to POST the credentials.

Is it working ?

cheers
Nicolas

7

Hi Josselin,

First of all, note that your warm up request times out (probably because you’re behind an internet proxy):
https://github.com/excilys/gatling/wiki/HTTP#wiki-auto-warmup

You can either disable this feature, or set up a suitable url.

Regarding the differences between your 2 Charles records, here’s what I see:

  • Your Gatling simulation points to websphereServer while your firefox browing point to websphereserver, not sure it matters though
  • Gatling incorrectly sends a application/x-www-form-urlencoded header when redirecting. Will fix, but not sure if that’s a real problem
  • Gatling’s cookies format is different
    Gatling:
    JSESSIONID=“0000EWscIph-lrx0uog27iDEjIn:-1”; $Path="/"; $Domain=websphereServer; LtpaToken2="+ImgCj15kKlsQU0NPkwf/As6w8Rw0jXZtoQp5rCSNKTNn5EC9hzErZpnhecPmclwjgUGGkHpS0uD9tTgCEboK/YA56JFZ+dXwegrjAx9YQJfuycheNIkfjs0049iQyseeysPOasxf2fdSb2fU1n+iAligbFzGqWYzsv8Hiz67CwEnDT/dEk1TuhK/bTdTlTSFrVJ1TFVkQtLPPPwNlY6E+7SqgViEs9bEdfTlgZTyIh1/5Mex7AiioAkP2Qz0nch5WELp85lWPZR6HUwEEx/ovAngiSJUKCCTdbslj8YScs2USz2RkobvlJcDRNfB4dCwHp/nxTuFcLe1uCgRaRU3mHEHuouDWNMCZR9PLYnDwukgEs46cqwNeMTNrkBV8f0ZEWdFM/0X1B4ZS1fiShFaPJHNnstAfOVgyqkg8Hez7jhCtAebYVDZFwSD6E+nbyDcU3wupRvawLtLHRfU4NCn2HIbvuOuIHLavlt+XIC5WCvmHeKUHekCgfDcKZrjdX4V3cVUI+d6DU7WiK8XqiHemm+8S89RB6rgHWb6IE6FbWHAzD6CgbX+/JnOAaRse8PEH3fzYw2ztBURlBZAqTBSi/yVdJT26R/8ObeK33MnIb+g88ZWK50U7rWM3Xn8yYjPYnZBjU2BIwjAuQTPvRR5w"; $Path="/"; $Domain=websphereServer

Firefox:
JSESSIONID=00000n9IvLxj1-o0shGZlxnFLTg:-1; LtpaToken2=+ImgCj15kKlsQU0NPkwf/As6w8Rw0jXZtoQp5rCSNKTNn5EC9hzErZpnhecPmclwjgUGGkHpS0uD9tTgCEboK/YA56JFZ+dXwegrjAx9YQJfuycheNIkfjs0049iQyseeysPOasxf2fdSb2fU1n+iAligbFzGqWYzsv8Hiz67CwEnDT/dEk1TuhK/bTdTlTSFrVJ1TFVkQtLPPPwNlY6E+7SqgViEs9bEdfTlgZTyIh1/5Mex7AiioAkP2Qz0nch5WELp85lWPZR6HUwEEx/ovAngiSJUKCCTdbslj8YScs2USz2RkobvlJcDRNfB4dCwHp/nxTuFcLe1uCgRaRU3mHEHuouDWNMCZR9PLYnDwukgEs46cqwNeMTNrkBV8f0ZEWdFM/0X1B4ZS1fiShFaPJHNnstAfOVgyqkg8Hez7jhCtAebYVDZFwSD6E+nbyDcU3wupRvawLtLHRfU4NCn2HIbvuOuIHLavlt+XIC5WCvmHeKUHekCgfDcKZrjdX4V3cVUI+d6DU7WiK8XqiHemm+8S89RB6rgHWb6IE6FbWHAzD6CgbX+/JnOAaRse8PEH3fzYw2ztBURlBZAqTBSi/yVdJT26R/8ObeK33MnIb+g88ZWK50U7rWM3Xn8yYjPYnZBjU2BIwjAuQTPvRR5w==

As you see, cookie values are protected with quotes, and path and domain are specified.
I have to check what the RFC says about this.

Note that Cookies are streamed in async-http-client, not in Gatling.

Cheers,

Stéphane

8

Stéphane,

The more important difference is that the POST /j_security_check done with Firefox contains this additionnal header :

Set-Cookie | WASReqURL=“”; Expires=Thu, 01-Dec-94 16:00:00 GMT; Path=/ |

  • | - |

Even though the cookie is expired, it show us that there is already a difference.

cheers,
Nicolas

9

Yep, I noticed that. It seems it’s a cookie for memorizing the landing page after authenticating.
I supposed/hoped that if none was specified, the LoginServlet would simply redirect to /, but maybe you’re right and it indeed matters.

10

Hi

@Nicolas Rémond

Following your advice, I’ve just tried requesting first an access-restricted page.
The call is directly redirected to the same LoginServlet, and afterwards the scenario follows the exact same path.

@Stéphane Landelle

  • Thanks for the tip for the warmup phase. I did read about this warmup in the documentation, but right now i’m not that worried about the accuracy of the performances results, so I let it be.
    I’ll disable it anyway, if only to clean-up the network captures.

  • “Your Gatling simulation points to websphereServer while your firefox browing point to websphereserver, not sure it matters though”
    This host is defined as “websphereServer” in my Windows’ host file, and it doesn’t appear to be case sensitive ; i’m using either one indifferently.
    I also tried specifying the IP directly ; no change whatsoever.

  • As for the headers and cookies, I also noticed these differences, but I don’t know enough about http headers to sort between relevant an irrelevant differences.
    I’ll try making some time to dig into these, if only for my personal knowledge.

Unfortunately, I currently don’t have much free time, so I won’t be able to mess with Gatling source code right now.
But if I can test things or provide you with any information that might help you improving Gatling, just ask, I’ll be happy to help out.

cheers,
Josselin

11

Hi,

@Nicolas Rémond

Following your advice, I’ve just tried requesting first an access-restricted page.
The call is directly redirected to the same LoginServlet, and afterwards the scenario follows the exact same path.

12

Hi,

For reference, I’ve uploaded the Charles’ tracing of the scenario starting with an access to a secured page here:
http://tsukilulu.free.fr/gatling/20121105/loginRecording_Gatling_firstQueryAnAccessRestrictedPage.chls

In this case, the response of the j_security_check does contain a

Set-Cookie | WASReqURL=“”; Expires=Thu, 01-Dec-94 16:00:00 GMT; Path=/ |

  • | - |

The cookies seems to be correctly used in the following queries.

cheers,
Josselin

13

Hi !

Any news on this issue ?
I know you’re kind of busy with the DEVOX coming soon, and just to be clear, I’m not pushing for a quick fix or anything.
But since I’m supposed to set-up performance tests during this month and my teamleader is kind of pushing, so I could use an estimation of work to be done / possible fix date,
just to know if I wait for a possible fix or fallback to a JMeter-based solution right away.

And if I could do/test anything for you, I’m here to help. =)

Thanks in advance,
Josselin.

14

Hi,

We have our talk this evening. I’ll try to find to time to have a lot today, otherwise will work on this tomorrow.

This only difference I can spot is that Gatling send cookies with a path and a domain, protected with quotes, while firefox doesn’t.

  • Firefox: WASReqURL=http://:9080/emcmn-portail/; JSESSIONID=00000n9IvLxj1-o0shGZlxnFLTg:-1
  • Gatling: JSESSIONID=“0000M4DJ_ojGOSfWR3V0VZ7E_gz:-1”; $Path="/"; $Domain=websphereServer; WASReqURL=“http://:9080/emcmn-portail/person/initCandidate.action”; $Path="/"; $Domain=websphereServer
    Cheers,

Stéphane

15

I might have found it:
https://github.com/excilys/gatling/issues/816

You should get a snapshot from Cloudbees in about 20 minutes.
https://gatling.ci.cloudbees.com/

http://repository-gatling.forge.cloudbees.com/snapshot/com/excilys/ebi/gatling/highcharts/gatling-charts-highcharts/1.4.0-SNAPSHOT/

Please let me know if it indeed fixes your problem.

Cheers,

Stéphane

PS: No more batteries, will come back online in a few hours hopefully.

16

Hi,

Thanks for the fast replies.

I took the snapshot gatling-charts-highcharts-1.4.0-20121112.114024-28-bundle.zip
and re-run the same scenario as before. (I just removed the hostHeader() call which doesn’t compile anymore)
And I got the same result : Websphere stills act like the calls are not authentificated and redirect to the login page. =/

Here are the Charles proxy recording and execution log :
http://tsukilulu.free.fr/gatling/20121112
Websphere’s log appears to be the same.

I’ve also tried to record a brand new scenario with gatling recorder and run it without modifying anything (except the host / proxy part, of course),
and the same error occurs.

Do you want me to check anything else ?

17

Other differences:

  • It seems that your Gatling simulation only accepts gzip and not deflate. Could you set up acceptEncodingHeader(“gzip, deflate”), please?
  • Could you try disabling keep-alive? Go in gatling.conf and set http.allowPoolingConnection to false
    Hope we’ll find out…

Stéphane

18

Could you try this replacement of gatling-http, please?
I’m at Devoxx right now and will be doing a demo in a few hours, so I don’t want to push something risky right now…

Cheers,

Stéphane

gatling-http-1.4.0-SNAPSHOT.jar (447 KB)

19

It seems that your Gatling simulation only accepts gzip and not deflate. Could you set up acceptEncodingHeader(“gzip, deflate”), please?

My gatling simulation’s httpConf is :

val httpConf = httpConfig
			.baseURL("[http://localhost:9081](http://localhost:9081)")
			.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
			.acceptLanguageHeader("en-us,en;q=0.7,fr;q=0.3")
			.acceptEncodingHeader("gzip, deflate")
                        [...]

Did I miss anything while to configure the acceptEncodingHeader?



> Could you try disabling keep-alive? Go in gatling.conf and set http.allowPoolingConnection to false


I set it to false into the gatling.conf of the snapshot, (and removed the heading #)

and removed all the "keep-alive" from the request headers in the scenario (just to be extra-sure),

same result.
20

Could you try the jar?