On 3 June 2011 02:48, sebb <seb...@gmail.com> wrote: > On 3 June 2011 02:32, Deepak Shetty <shet...@gmail.com> wrote: >> Ok i will . Visually the cookies look fine and one of them does get sent in >> the next request (the one without path and http only) > > When I try, I get several cookies rejected, e.g. with the message: > > (Illegal path attribute "/testjmeter/wp-admin". Path of origin: > "/testjmeter/wp-login.php") > > Maybe that is part of the problem?
I'd forgotten - there is a JMeter property one can set to avoid checking cookies for validity: CookieManager.check.cookies=false Setting that prevents the invalid cookie paths from being rejected. >> Daniel : see if >> http://cid-1bd02fe33f80b8ac.office.live.com/self.aspx/Public/jmeter/wordpress.jmxworks >> for you. I added the missing cookie programattically (various >> hardcodes but you shoould be able to login - logout doesnt work because I >> need to remove the cookie i set) >> >> regards >> deepak >> >> On Thu, Jun 2, 2011 at 6:18 PM, sebb <seb...@gmail.com> wrote: >> >>> On 3 June 2011 02:10, Deepak Shetty <shet...@gmail.com> wrote: >>> > 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 >>> >>> Perhaps not - please enable Cookie Manager Debug logging to see if any >>> of the cookies have been rejected, and why. >>> >>> > 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 <seb...@gmail.com> 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 <daniel.watr...@gmail.com> 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 <seb...@gmail.com> wrote: >>> >> >> On 2 June 2011 17:26, Bruce Ide <flyingrhenqu...@gmail.com> 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: jmeter-user-unsubscr...@jakarta.apache.org >>> >> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> >> >>> >> >> >>> >> > >>> >> > --------------------------------------------------------------------- >>> >> > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> > >>> >> > >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
