Guest safitch Report post Posted July 9, 2008 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? Quote Share this post Link to post Share on other sites
Guest angela Report post Posted July 10, 2008 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? Quote Share this post Link to post Share on other sites
Guest safitch Report post Posted July 21, 2008 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 Quote Share this post Link to post Share on other sites