subject:"Re\: cookie manager"

Re: cookie manager not working

2011-06-03 Thread sebb

On 3 June 2011 05:01, Daniel Watrous daniel.watr...@gmail.com wrote:
 Thank You.

 This works wonderfully. It's exactly what I was hoping to be able to
 accomplish. You all really went the extra mile to help me out.

 Can anyone tell me why my exclude definitions on the proxy didn't
 exclude the files I expected?

I already answered that. Probably spurious characters in the regexes.

BTW, you can select the Workbench and save it to a file, then Merge it later.

 Daniel

 On Thu, Jun 2, 2011 at 9:27 PM, Deepak Shetty shet...@gmail.com wrote:
 You are right , that is the problem . However im wondering what the right
 behavior is
 If I request /testjmeter/wp-login.php
 Then arent these valid paths for set-cookie
 /
 /testjmeter
 /testjmeter/wp-login.php
 /testjmeter/child/  -- This is the problematic one. I was under the
 impression this was allowed?

 if my page is at the root /wp-login.php then I think all directories under /
 are allowed in the Set-Cookie?

 I tried to look through the cookie RFC and didnt seem to find information
 one way or the other

 I can verify your fix works
 CookieManager.check.cookies=false -- Daniel this should work without needing
 to manipulate cookies (In my example set this in jmeter.properties and
 disable the pre processor that adds the cookie)



 regards
 deepak






 On Thu, Jun 2, 2011 at 6:48 PM, 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?

  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

Re: cookie manager not working

2011-06-03 Thread sebb

On 3 June 2011 04:27, Deepak Shetty shet...@gmail.com wrote:
You are right , that is the problem . However im wondering what the right
behavior is
If I request /testjmeter/wp-login.php
Then arent these valid paths for set-cookie
/
/testjmeter
/testjmeter/wp-login.php
/testjmeter/child/ -- This is the problematic one. I was under the
impression this was allowed?

The Netscape specs (such as they are) are not entirely clear on this.
I have found the following:

[1] the pathname component of the URL is compared with the path
attribute, and if there is a match, the cookie is considered valid and
is sent along with the URL request. The path /foo would match
/foobar and /foo/bar.html. The path / is the most general path.

RFC2109 says cookies should be rejected if The value for the Path
attribute is not a prefix of the request-URI.

My reading is that /testjmeter/child/ is not allowed by either cookie spec.

if my page is at the root /wp-login.php then I think all directories under /
are allowed in the Set-Cookie?

If the path is set to /, then all files and directories under it are allowed.
However, as far as I can tell, if the path is set to /wp-login.php
then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
that exists)

I tried to look through the cookie RFC and didnt seem to find information
one way or the other

See above.

I can verify your fix works
CookieManager.check.cookies=false -- Daniel this should work without needing
to manipulate cookies (In my example set this in jmeter.properties and
disable the pre processor that adds the cookie)

Best to add this to user.properties

[1] http://curl.haxx.se/rfc/cookie_spec.html
[2]
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html

-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org

Re: cookie manager not working

2011-06-03 Thread Deepak Shetty

even www.wordpress.com does the same thing and it seems to work fine in FF

*https://en.wordpress.com/wp-login.php*
POST /wp-login.php HTTP/1.1
Set-Cookie: wordpress=VALUE; expires=Fri, 17-Jun-2011 19:32:09 GMT; *
path=/wp-admin;* domain=.wordpress.com; httponly

the browser is at url / , the post is to url */wp-login.php *- what is the
path to be compared with - the url the browser is at or the URL that is
being posted to. ?


regards
deepak


On Fri, Jun 3, 2011 at 4:26 AM, sebb seb...@gmail.com wrote:

 On 3 June 2011 04:27, Deepak Shetty shet...@gmail.com wrote:
  You are right , that is the problem . However im wondering what the right
  behavior is
  If I request /testjmeter/wp-login.php
  Then arent these valid paths for set-cookie
  /
  /testjmeter
  /testjmeter/wp-login.php
  /testjmeter/child/  -- This is the problematic one. I was under the
  impression this was allowed?

 The Netscape specs (such as they are) are not entirely clear on this.
 I have found the following:

 [1] the pathname component of the URL is compared with the path
 attribute, and if there is a match, the cookie is considered valid and
 is sent along with the URL request. The path /foo would match
 /foobar and /foo/bar.html. The path / is the most general path.

 RFC2109 says cookies should be rejected if The value for the Path
 attribute is not a prefix of the request-URI.

 My reading is that  /testjmeter/child/ is not allowed by either cookie
 spec.

  if my page is at the root /wp-login.php then I think all directories
 under /
  are allowed in the Set-Cookie?

 If the path is set to /, then all files and directories under it are
 allowed.
 However, as far as I can tell, if the path is set to /wp-login.php
 then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
 that exists)

  I tried to look through the cookie RFC and didnt seem to find information
  one way or the other

 See above.

  I can verify your fix works
  CookieManager.check.cookies=false -- Daniel this should work without
 needing
  to manipulate cookies (In my example set this in jmeter.properties and
  disable the pre processor that adds the cookie)

 Best to add this to user.properties

 [1] http://curl.haxx.se/rfc/cookie_spec.html
 [2]
 http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html

 -
 To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
 For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org

Re: cookie manager not working

2011-06-03 Thread sebb

On 3 June 2011 20:36, Deepak Shetty shet...@gmail.com wrote:
 even www.wordpress.com does the same thing and it seems to work fine in FF

 *https://en.wordpress.com/wp-login.php*
 POST /wp-login.php HTTP/1.1
 Set-Cookie: wordpress=VALUE; expires=Fri, 17-Jun-2011 19:32:09 GMT; *
 path=/wp-admin;* domain=.wordpress.com; httponly

 the browser is at url / , the post is to url */wp-login.php *- what is the
 path to be compared with - the url the browser is at or the URL that is
 being posted to. ?

AIUI, the cookie path is to be compared with the current request URI,
i.e. /wp-login.php


 regards
 deepak


 On Fri, Jun 3, 2011 at 4:26 AM, sebb seb...@gmail.com wrote:

 On 3 June 2011 04:27, Deepak Shetty shet...@gmail.com wrote:
  You are right , that is the problem . However im wondering what the right
  behavior is
  If I request /testjmeter/wp-login.php
  Then arent these valid paths for set-cookie
  /
  /testjmeter
  /testjmeter/wp-login.php
  /testjmeter/child/  -- This is the problematic one. I was under the
  impression this was allowed?

 The Netscape specs (such as they are) are not entirely clear on this.
 I have found the following:

 [1] the pathname component of the URL is compared with the path
 attribute, and if there is a match, the cookie is considered valid and
 is sent along with the URL request. The path /foo would match
 /foobar and /foo/bar.html. The path / is the most general path.

 RFC2109 says cookies should be rejected if The value for the Path
 attribute is not a prefix of the request-URI.

 My reading is that  /testjmeter/child/ is not allowed by either cookie
 spec.

  if my page is at the root /wp-login.php then I think all directories
 under /
  are allowed in the Set-Cookie?

 If the path is set to /, then all files and directories under it are
 allowed.
 However, as far as I can tell, if the path is set to /wp-login.php
 then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
 that exists)

  I tried to look through the cookie RFC and didnt seem to find information
  one way or the other

 See above.

  I can verify your fix works
  CookieManager.check.cookies=false -- Daniel this should work without
 needing
  to manipulate cookies (In my example set this in jmeter.properties and
  disable the pre processor that adds the cookie)

 Best to add this to user.properties

 [1] http://curl.haxx.se/rfc/cookie_spec.html
 [2]
 http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html

 -
 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

Re: cookie manager not working

2011-06-03 Thread Deepak Shetty

I guess my confusion arises because most of the text talks about restricting
the scope of the cookies and the RFC only allows you to broaden the scope.In
any case the workaround is more than sufficient for these cases

regards
deepak


On Fri, Jun 3, 2011 at 1:05 PM, sebb seb...@gmail.com wrote:

 On 3 June 2011 20:36, Deepak Shetty shet...@gmail.com wrote:
  even www.wordpress.com does the same thing and it seems to work fine in
 FF
 
  *https://en.wordpress.com/wp-login.php*
  POST /wp-login.php HTTP/1.1
  Set-Cookie: wordpress=VALUE; expires=Fri, 17-Jun-2011 19:32:09 GMT; *
  path=/wp-admin;* domain=.wordpress.com; httponly
 
  the browser is at url / , the post is to url */wp-login.php *- what is
 the
  path to be compared with - the url the browser is at or the URL that is
  being posted to. ?

 AIUI, the cookie path is to be compared with the current request URI,
 i.e. /wp-login.php

 
  regards
  deepak
 
 
  On Fri, Jun 3, 2011 at 4:26 AM, sebb seb...@gmail.com wrote:
 
  On 3 June 2011 04:27, Deepak Shetty shet...@gmail.com wrote:
   You are right , that is the problem . However im wondering what the
 right
   behavior is
   If I request /testjmeter/wp-login.php
   Then arent these valid paths for set-cookie
   /
   /testjmeter
   /testjmeter/wp-login.php
   /testjmeter/child/  -- This is the problematic one. I was under the
   impression this was allowed?
 
  The Netscape specs (such as they are) are not entirely clear on this.
  I have found the following:
 
  [1] the pathname component of the URL is compared with the path
  attribute, and if there is a match, the cookie is considered valid and
  is sent along with the URL request. The path /foo would match
  /foobar and /foo/bar.html. The path / is the most general path.
 
  RFC2109 says cookies should be rejected if The value for the Path
  attribute is not a prefix of the request-URI.
 
  My reading is that  /testjmeter/child/ is not allowed by either cookie
  spec.
 
   if my page is at the root /wp-login.php then I think all directories
  under /
   are allowed in the Set-Cookie?
 
  If the path is set to /, then all files and directories under it are
  allowed.
  However, as far as I can tell, if the path is set to /wp-login.php
  then it is only valid for /wp-login.php (and ./wp-login.php/xzy if
  that exists)
 
   I tried to look through the cookie RFC and didnt seem to find
 information
   one way or the other
 
  See above.
 
   I can verify your fix works
   CookieManager.check.cookies=false -- Daniel this should work without
  needing
   to manipulate cookies (In my example set this in jmeter.properties and
   disable the pre processor that adds the cookie)
 
  Best to add this to user.properties
 
  [1] http://curl.haxx.se/rfc/cookie_spec.html
  [2]
 
 http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/cookies.html
 
  -
  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

Re: cookie manager not working

2011-06-02 Thread Daniel Watrous

I'm still struggling with this. I've made the following video that
will hopefully give enough detail to help me along:
http://www.screencast.com/t/Dafijet8P9VS

I've also created a test site if that helps you troubleshoot this issue with me.
http://authnet.danielwatrous.com/testjmeter/
username: admin
password: test

The log file had to do with permissions. When I moved the jmeter files
outside of the program files folder it was able to create the log
file.

Thank you.

On Wed, Jun 1, 2011 at 7:40 PM, sebb seb...@gmail.com wrote:
 On 2 June 2011 02:06, Daniel Watrous daniel.watr...@gmail.com wrote:
 I've discovered that the cookies sent back by wordpress have an
 expires value one year before the date of the request. Browsers seem
 to store this as a session cookie, but I'm not sure why. Is there some
 way to tell the cookie manager to deal with these cookies that have an
 expires value before right now?

 No, not without modifying JMeter code.
 However, by judicious use of the Regex Extractor you should be able to
 extract the cookie from the header and then add it using a Header
 Manager.

 I've put in a post on the wordpress forum to figure out why they do it that 
 way.

 I also can't find a log file. How can I troubleshoot the reason a log
 file won't write?

 Check if the launch directory is writable. Are you sure there is no
 jmeter.log file?

 Daniel

 On Fri, May 27, 2011 at 7:29 AM, sebb seb...@gmail.com wrote:
 On 27 May 2011 14:17, Daniel Watrous daniel.watr...@gmail.com wrote:
 I had actually tried that before mailing to the list. I just tried it
 again with no change to whether cookies are sent or not.

 In that case, you'll need to enable debug logging  for the Cookie
 Manager: select it and use the Menu item Help/Enable Debug

 Output will be in the log file.

 I can't find the log file, but here's my java version:

 Unless you override the location in the jmeter.properties file, the
 log file will be in the directory where you started JMeter from, by
 default the bin directory, and will be called jmeter.log.

 C:\Program Files (x86)\Console2java -version
 java version 1.6.0_20
 Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
 Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

 C:\Program Files (x86)\Console2

 Windows 7 x64

 thanks,

 Daniel



 On Fri, May 27, 2011 at 3:03 AM, sebb seb...@gmail.com wrote:
 On 27 May 2011 08:48, sebb seb...@gmail.com wrote:
 On 27 May 2011 06:47, Daniel Watrous daniel.watr...@gmail.com wrote:
 Hello,

 I've been trying to setup a jmeter program to test a wordpress plugin.
 However, I can't get the login to work. It appears to be sending the
 cookies back correctly when the login is sent, but they don't get
 picked up by the cookie manager.

 I've been searching for a while and looked at dozens of examples.
 Maybe you can spot what I've done wrong from these screenshots:

 http://screencast.com/t/EW1zAgvlK
 http://screencast.com/t/2i8dTyBh
 http://screencast.com/t/fd5dGPvCb

 The Cookie Manager is set to require RFC2109 cookies; these have a
 specific format that is not always followed by servers (or browsers).

 The default is supposed to be compatibility mode, try using that.

 What version of Java are you using? This will be shown near the start
 of the jmeter.log file, e.g.

 java.version=1.5.0_22
 java.vm.name=Java HotSpot(TM) Client VM

 I've just noticed that the default when adding a new Cookie Manager is
 set correctly to compatibility (first option) when using that

 Actually it's the last option when using Java 1.5, first when using
 1.6 - which is where the problem lies ...

 version, however when using

 java.version=1.6.0_25
 java.vm.name=Java HotSpot(TM) Client VM

 which is the current Java version it is set to rfc109 (the last 
 option).

 This is odd, since the code specifically tries to set compatibility 
 mode.
 Looks like there may be a Java bug (or at least a change in behaviour).

 It's a change in Java behaviour - the order of cookie policies is
 different, because of internal changes to the libraries.

 JMeter incorrectly relies on the order of the entries. Oops.

 However, there's an easy work-round - just change the policy to 
 compatibility.


 Thanks in advance.

 Daniel

 -
 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:

Re: cookie manager not working

2011-06-02 Thread Bruce Ide

Jmeter's doing the right thing. If you're testing wordpress, file a bug with
them and tell them to fix their thing. If you're running an application
server yourself, I'd suspect it's something wrong with your application
server config.

You have the jmeter source, you could always change its behavior to do what
you want and recompile it. I'd start with CookieManager.java:

while (cookies.hasNext()) {
Cookie cook = (Cookie) cookies.next().getObjectValue();
final long expiresMillis = cook.getExpiresMillis();
if (expiresMillis == 0 || expiresMillis  now) { // only save
unexpired cookies
writer.println(cookieToString(cook));
}
}

Well there's your problem! I can't guarantee that's the only thing that
prevents expired cookies from being sent. I suspect there's probably also
some code in httpclient that checks to see if they're expired before sending
them back.

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.

-- 
Bruce Ide
flyingrhenqu...@gmail.com

Re: cookie manager not working

2011-06-02 Thread Daniel Watrous

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.

Is there a jobs board for jmeter where I could hire a guru to get my
tests going?

Daniel

On Thu, Jun 2, 2011 at 9:35 AM, Bruce Ide flyingrhenqu...@gmail.com wrote:
 Jmeter's doing the right thing. If you're testing wordpress, file a bug with
 them and tell them to fix their thing. If you're running an application
 server yourself, I'd suspect it's something wrong with your application
 server config.

 You have the jmeter source, you could always change its behavior to do what
 you want and recompile it. I'd start with CookieManager.java:

        while (cookies.hasNext()) {
            Cookie cook = (Cookie) cookies.next().getObjectValue();
            final long expiresMillis = cook.getExpiresMillis();
            if (expiresMillis == 0 || expiresMillis  now) { // only save
 unexpired cookies
                writer.println(cookieToString(cook));
            }
        }

 Well there's your problem! I can't guarantee that's the only thing that
 prevents expired cookies from being sent. I suspect there's probably also
 some code in httpclient that checks to see if they're expired before sending
 them back.

 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.

 --
 Bruce Ide
 flyingrhenqu...@gmail.com


-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org

Re: cookie manager not working

2011-06-02 Thread sebb

On 2 June 2011 16:35, Bruce Ide flyingrhenqu...@gmail.com wrote:
 Jmeter's doing the right thing. If you're testing wordpress, file a bug with
 them and tell them to fix their thing. If you're running an application
 server yourself, I'd suspect it's something wrong with your application
 server config.

I'm inclined to agree - as far as I can tell, session cookies are
cookies without an expiry date or age.

 You have the jmeter source, you could always change its behavior to do what
 you want and recompile it. I'd start with CookieManager.java:

        while (cookies.hasNext()) {
            Cookie cook = (Cookie) cookies.next().getObjectValue();
            final long expiresMillis = cook.getExpiresMillis();
            if (expiresMillis == 0 || expiresMillis  now) { // only save
 unexpired cookies
                writer.println(cookieToString(cook));
            }
        }

 Well there's your problem!

That only affects the cookies that are stored in the cookies file
(which is not normally used).

 I can't guarantee that's the only thing that
 prevents expired cookies from being sent. I suspect there's probably also
 some code in httpclient that checks to see if they're expired before sending
 them back.

Yes.
JMeter currently uses the Commons HttpClient 3.1 cookie handling code.

 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].

Note that cookies won't be handled properly if you have selected
redirect automatically, because then JMeter does not see the cookies

 --
 Bruce Ide
 flyingrhenqu...@gmail.com


-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org

Re: cookie manager not working

2011-06-02 Thread Bruce Ide

  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!


  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.

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.

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.

-- 
Bruce Ide
flyingrhenqu...@gmail.com

Re: cookie manager not working

2011-06-02 Thread sebb

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

Re: cookie manager not working

2011-06-02 Thread Daniel Watrous

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

Re: cookie manager not working

2011-06-02 Thread Deepak Shetty

Hi
where are you seeing the invalid cookies(sorry havent seen your screencast).
i tried with firefox to login
I get

*http://authnet.danielwatrous.com/testjmeter/wp-login.php*

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/testjmeter/
Set-Cookie:
wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307234422%7Cc8c4e5bb5f9bacc38cf0d3f6a5a19125;
path=/testjmeter/wp-content/plugins; httponly
Set-Cookie:
wordpress_44389825f27c6e6c84e4f25396df08b1=admin%7C1307234422%7Cc8c4e5bb5f9bacc38cf0d3f6a5a19125;
path=/testjmeter/wp-admin; httponly
Set-Cookie:
wordpress_logged_in_44389825f27c6e6c84e4f25396df08b1=admin%7C1307234422%7C0499d7fe3fd97c79cefda4d96eb98156;
path=/testjmeter/; httponly

*http://authnet.danielwatrous.com/testjmeter/wp-admin/*

Set-Cookie:
wp-settings-1=m8%3Dc%26m6%3Dc%26m10%3Dc%26m11%3Do%26m7%3Do%26m4%3Dc%26m12%3Dc%26m0%3Dc%26m1%3Dc;
expires=Sat, 02-Jun-2012 00:40:23 GMT; path=/testjmeter/
Set-Cookie: wp-settings-time-1=1307061623; expires=Sat, 02-Jun-2012 00:40:23
GMT; path=/testjmeter/

Atleast the browser behaves correctly - as far as I remember setting the
expiry date to the past is equivalent to deleting the cookie - so if you set
expiry in the past , then the browser wont send the cookie either

regards
deepak

On Thu, Jun 2, 2011 at 5:30 PM, Daniel Watrous daniel.watr...@gmail.comwrote:

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

Re: cookie manager not working

2011-06-02 Thread sebb

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:

Re: cookie manager not working

2011-06-02 Thread Deepak Shetty

There seems to be a Jmeter Bug

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 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.

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:

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.

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

Re: cookie manager not working

2011-06-02 Thread sebb

On 3 June 2011 02:10, Deepak Shetty shet...@gmail.com wrote:
There seems to be a Jmeter Bug

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