There seems to be a Jmeter Bug Login request gets the following as response
Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/ Set-Cookie: wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1; path=/testjmeter/wp-content/plugins; httponly *Set-Cookie: wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7Ca053ec10f70ffb4681edbea2e9c65bf1; path=/testjmeter/wp-admin; httponly *Set-Cookie: wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1; All good here The next request GET http://authnet.danielwatrous.com/testjmeter/wp-admin/ Cookie Data: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307235979%7C33bd157a96bcaf545769fa5d4b8483e1 doesnt have the cookie above that I bolded which has an explicit path and httponly (not sure which of the attributes cause a problem) Programatically setting the cookies seem to be the only workaround without code fix, can you please confirm (I dont think expiry date has naything to do with , like you say , past expiry is used to delete a cookie) regards deepak On Thu, Jun 2, 2011 at 5:52 PM, sebb <[email protected]> wrote: > Yes; perhaps it is deliberately sending expired dates in order to > delete the cookies. I have seen another server do this. > > From some biref experiments with your test site, I suspect the login > problem is nothing to do with expired cookies after all, but there is > probably some other setting that is not correct. > > Look for parameters that have odd-looking values; they may be being > set by Javascript in the browser, in which case you will have to work > out how to extract the relevant values from the previous reponse. > > Or record the login twice, and compare the generated test plans to see > which entries have changed. You then have to work out how to extract > the values they need. The Save Responses to a File Listener can be > helpful here. > > BTW, JMeter cannot currently handle deflate encoding, so make sure you > don't enable that in the Header Manager. > > Also, Excludes *do* work - make sure that there aren't any trailing > spaces or other spurious characters in the fields. > > On 3 June 2011 01:30, Daniel Watrous <[email protected]> wrote: > > Did any of you notice that the Date of the request is accurate and so > > are some of the cookies? WordPress seems to deliberately send the > > login related cookies with the year old expiration. Others are fine. > > > > I mention this because there seems to be an idea that the server time > > is configured wrong. > > > > On Thu, Jun 2, 2011 at 4:32 PM, sebb <[email protected]> wrote: > >> On 2 June 2011 17:26, Bruce Ide <[email protected]> wrote: > >>> > I think it's a bit premature to suggest that WordPress is broken. It > >>> > is used on tens of millions of sites and people are able to login > fine > >>> >every day. > >>> > >>> Number of users is not a quality metric! Look at Windows... (Heh heh > heh) > >>> > >>>> Well there's your problem! > >>>> > >>>> That only affects the cookies that are stored in the cookies file > >>>> (which is not normally used). > >>>> > >>>> > >>> Doh! It seemed like such a likely culprit, too! > >>> > >> > >> The actual expiry code is similar: > >> > >> // Store session cookies as well as unexpired ones > >> if (exp == 0 || exp >= System.currentTimeMillis()) { > >> newCookie.setVersion(cookie.getVersion()); > >> add(newCookie); // Has its own debug log; removes > >> matching cookies > >> } else { > >> removeMatchingCookies(newCookie); > >> if (debugEnabled){ > >> log.debug("Dropping expired Cookie: > >> "+newCookie.toString()); > >> } > >> } > >> > >> > >>> > >>>> > I'd be really hesitant to change the behavior of the test > environment to > >>>> > mask a bug you uncovered, though. Sending expired cookies IS a bug, > and > >>>> it's > >>>> > something the guys running the server should fix. > >>>> > >>>> If this is a general problem, I suppose it might make sense to add an > >>>> option to remove the expiry date from stale cookies, turning them into > >>>> session cookies. > >>>> But AFAIK this is the first time this has been reported [, and might > >>>> cause indigestion (!) in some cases]. > >>>> > >>>> > >>> Well it sounds like the web browser is also storing and using the > expired > >>> cookie, and the remote server is honoring it! That's like 3 different > bugs > >>> he's uncovered so far! At this point I'd be rampaging like... something > that > >>> rampages a LOT... through 2 or 3 different bug forums. > >>> > >>> I'm sure the Firefox guys would say "No it's not!" At least some people > in > >>> the "real world" do check cookie expiry dates, but it's probably > "optional". > >>> I'm not inclined to go digging through RFCs to find out. > >>> > >>> I'd say Wordpress sending out cookies from last year means someone > hasn't > >>> been minding a server like they should be. That really IS a problem. > >> > >> Agreed. > >> > >>> I suppose you could add a "Remove expiration dates" to the cookie > manager > >>> panel, or a "send expired cookies" checkbox to the httpclient. Probably > >>> wouldn't be a huge amount of coding, and would probably be only vaguely > >>> atrocious. > >> > >> It's fairly simple to change the code itself, but there is additional > >> work needed to implement the GUI change and update the documentation. > >> > >> It's not yet clear if this is a general problem affecting multiple > >> servers, or just WordPress servers, or just an issue with the > >> particular WordPress host. > >> > >>> Or perhaps a sampler or postprocessor that allows you to manipulate > explicit > >>> cookie values? That'd be a bit more work, but might be more palatable. > >> > >> That can be done already with the Regex Processor and Header Manager, > >> or using the BSH or BSF test elements. > >> > >> Might just be simpler to change the time on the box running JMeter ... > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
