Jump to content
WAPT Forum
Sign in to follow this  
Guest safitch

Cookie trouble

Recommended Posts

Guest 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?

Share this post


Link to post
Share on other sites
Guest 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?

 

Share this post


Link to post
Share on other sites
Guest 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?

Logs.zip

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×