jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: cookie manager not working
Date Fri, 03 Jun 2011 10:52:35 GMT
On 3 June 2011 05:01, Daniel Watrous <daniel.watrous@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 <shettyd@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 <sebbaz@gmail.com> wrote:
>>
>>> On 3 June 2011 02:32, Deepak Shetty <shettyd@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 <sebbaz@gmail.com> wrote:
>>> >
>>> >> On 3 June 2011 02:10, Deepak Shetty <shettyd@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 <sebbaz@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.watrous@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 <sebbaz@gmail.com>
wrote:
>>> >> >> >> On 2 June 2011 17:26, Bruce Ide <flyingrhenquest@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-unsubscribe@jakarta.apache.org
>>> >> >> >> For additional commands, e-mail:
>>> jmeter-user-help@jakarta.apache.org
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> ---------------------------------------------------------------------
>>> >> >> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> >> > For additional commands, e-mail:
>>> jmeter-user-help@jakarta.apache.org
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

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


Mime
View raw message