[safitch]

Hi, I've been testing out your product for a web application my team is developing. We have some issues getting cookies to work correctly. To explain, when a user logs in, we set two cookies, one for the base path of the domain, eg /, this cookie is initially set by the application server 1 which serves the login pages. It is a typical JSESSIONID=342342... used only for user authentication purposes. The login pages are served by a legacy system. But in addition to that, some part of the page is served by another application server 2, which also sets a cookie JSESSIONID=54050... (distinct from the first one). But this cookie has its path set to /ournewebapp When recording the test, if I try to first log in, both cookies are set (with the paths differing as explained) . If I then try to access a protected page under the /ournewebapp path, it goes smoothly because the browser seems to know to send the cookie which matches the path (the one set by appserv 2), hence authenticating the user on application server 2. This however does not seem to work when trying to run a test. What happens is that both cookies get set initially, but when trying to access a page under the /ournewebapp path, the cookie of the root path / is sent in the header, not the expected /ournewebapp cookie, hence we get an 403 error from application server 2, because we don't send the correct JSESSIONID. Why this distinct behaviour between recording and run? Are there some workarounds?

[angela]

Hi, I've been testing out your product for a web application my team is developing. We have some issues getting cookies to work correctly. To explain, when a user logs in, we set two cookies, one for the base path of the domain, eg /, this cookie is initially set by the application server 1 which serves the login pages. It is a typical JSESSIONID=342342... used only for user authentication purposes. The login pages are served by a legacy system. But in addition to that, some part of the page is served by another application server 2, which also sets a cookie JSESSIONID=54050... (distinct from the first one). But this cookie has its path set to /ournewebapp When recording the test, if I try to first log in, both cookies are set (with the paths differing as explained) . If I then try to access a protected page under the /ournewebapp path, it goes smoothly because the browser seems to know to send the cookie which matches the path (the one set by appserv 2), hence authenticating the user on application server 2. This however does not seem to work when trying to run a test. What happens is that both cookies get set initially, but when trying to access a page under the /ournewebapp path, the cookie of the root path / is sent in the header, not the expected /ournewebapp cookie, hence we get an 403 error from application server 2, because we don't send the correct JSESSIONID. Why this distinct behaviour between recording and run? Are there some workarounds?

Hi,

Could you please send to us your scenario, profile, Full and Error logs generated by WAPT?

[safitch]

The files are attached.

In the log file, please notice the following:

When logging in the following is set as a response from (as can be shown in the log file):

POST /login HTTP/1.1
Set-Cookie: JSESSIONID=LGJhs1y1G2vXlVBd9wpGyT2zxyGc1tnYC3Dsv82wlJl07vh5zDjJ!1793798701; path=/ <- this is the app server 1 cookie


Set-Cookie: JSESSIONID=5b9992217a14b5b89e8af0f62064; path=/app24 <- this is the app server 2 cookie

So when accessing files on /app24 one should expect that the /app24 cookie is sent. however, on line 3802 in the log
the following happens:

GET /app24/financial_applications HTTP/1.1
Cookie: JSESSIONID=LGJ49Gdw1ySC1hfgZ2v5J4CLZNNhbgSLmyJcTCPJcQlBhrSz6L6Q!1793798701

Of course the app server 2 doesn't reckognize the JSESSIONID and is expecting the cookie set on the /app24 path, resulting in a halting
HTTP/1.1 403 Forbidden on line 3816

Why doesn't WAPT send the right cookie in this case?

Attached File(s)

•  Logs.zip (11.24K)
  Number of downloads: 13