Re: Login failed - javascript
On 12 June 2013 14:24, nmq wrote:
> FYI! Deepak was correct. There's also a cookie being set.
> I just used the script generated by BadBoy and it recorded the HTTP request
> with a cookie value which is of course a static value.
> So now I need to extract the cookie value using a regular expression and
> then use it.
> I'm going to try and figure out how to do this.
Unless the cookie is being set by Javascript, just add a Cookie Manager.
> Thanks
> Sam
>
>
>
>
>
>
>
> On Wed, Jun 12, 2013 at 8:29 AM, nmq wrote:
>
>> Thanks guys.
>>
>> I was able to log in finally. Tried a lot of stuff, but what worked was
>> unchecking "redirect automatically" on the HTTP samplers. I would like to
>> figure out why unchecking "redirect automatically" made a difference.
>> Insights? Opinions?
>>
>> Thanks
>> Sam
>>
>>
>> On Tue, Jun 11, 2013 at 11:57 PM, Robin D. Wilson wrote:
>>
>>> By the way, this is where recording a login using the HTTP Proxy Recorder
>>> would help up you figure this problem out.
>>>
>>> --
>>> Robin D. Wilson
>>> VOICE: 512-777-1861
>>>
>>>
>>>
>>> On Jun 11, 2013, at 10:54 PM, "Robin D. Wilson"
>>> wrote:
>>>
>>> It appears to me that the way this works is to hide/unhide some elements
>>> on the page using JavaScript. The way that would work is to hide an element
>>> that says "you must enable JavaScript" and unhide an element that has the
>>> login form on it.
>>>
>>> If that is the case, then you can just ignore the "you must enable
>>> JavaScript" warning, and just submit the form anyway. The server has no way
>>> to know whether the browser hid/un-hid anything, so if you submit the login
>>> form it will assume you saw the login form.
>>>
>>> When you are looking in the tree listener, are you looking at the "text"
>>> of the response, or are you looking at the rendered HTML? You really need
>>> to look at the "text" since that's what JMeter actually sees. It may be a
>>> "red herring" to assume that the JavaScript warning makes a difference
>>> since you are looking at the response in a tool (the Tree Listener) that
>>> doesn't execute the JavaScript, and never will.
>>>
>>> --
>>> Robin D. Wilson
>>> VOICE: 512-777-1861
>>>
>>>
>>>
>>> On Jun 11, 2013, at 9:41 PM, nmq wrote:
>>>
>>> Take a look at this code snippet I found for the login page.
>>>
>>>
>>> // activate login feature if script is activated and browser is supported
>>> if ($.browser.msie && $.browser.version < 8) {
>>> $('#browser-redirection').css('display', '');
>>> } else {
>>> $('.script-checking').css('display', '');
>>> $('#warnings').css('display', 'none');
>>> }
>>>
>>>
>>> So my understanding is that the login feature is not getting activated at
>>> all as JMeter does not run javascript.
>>> Is that correct?
>>> Is there any way for me to simulate a user logging in with this situation?
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
>>>
>>> >> . If the recorded requests have the same problems as your test plan
>>> did,
>>> > which is fairly common when you have dynamic data and is not a good
>>> > indicator.
>>> >
>>> >
>>> >
>>> > On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
>>> > wrote:
>>> >
>>> >> If you use the Proxy setup, you can then just 'replay' the previous
>>> >> requests and see if they have the same problem as you were
>>> >> having. Basically, disable your test requests, and copy/paste the ones
>>> >> from the Proxy recording in their place. Run the test using
>>> >> the recorded requests, and watch the Tree Listener for the responses
>>> from
>>> >> the server. If the recorded requests have the same
>>> >> problems as your test plan did, then you will definitely need to
>>> discuss
>>> >> with your developers (maybe it's just a bug in their
>>> >> code?). If the recorded proxy script works normally, then you have a
>>>
Re: Login failed - javascript
On 12 June 2013 13:29, nmq wrote:
> Thanks guys.
>
> I was able to log in finally. Tried a lot of stuff, but what worked was
> unchecking "redirect automatically" on the HTTP samplers. I would like to
> figure out why unchecking "redirect automatically" made a difference.
> Insights? Opinions?
Redirect automatically does not handle cookies.
> Thanks
> Sam
>
>
> On Tue, Jun 11, 2013 at 11:57 PM, Robin D. Wilson wrote:
>
>> By the way, this is where recording a login using the HTTP Proxy Recorder
>> would help up you figure this problem out.
>>
>> --
>> Robin D. Wilson
>> VOICE: 512-777-1861
>>
>>
>>
>> On Jun 11, 2013, at 10:54 PM, "Robin D. Wilson"
>> wrote:
>>
>> It appears to me that the way this works is to hide/unhide some elements
>> on the page using JavaScript. The way that would work is to hide an element
>> that says "you must enable JavaScript" and unhide an element that has the
>> login form on it.
>>
>> If that is the case, then you can just ignore the "you must enable
>> JavaScript" warning, and just submit the form anyway. The server has no way
>> to know whether the browser hid/un-hid anything, so if you submit the login
>> form it will assume you saw the login form.
>>
>> When you are looking in the tree listener, are you looking at the "text"
>> of the response, or are you looking at the rendered HTML? You really need
>> to look at the "text" since that's what JMeter actually sees. It may be a
>> "red herring" to assume that the JavaScript warning makes a difference
>> since you are looking at the response in a tool (the Tree Listener) that
>> doesn't execute the JavaScript, and never will.
>>
>> --
>> Robin D. Wilson
>> VOICE: 512-777-1861
>>
>>
>>
>> On Jun 11, 2013, at 9:41 PM, nmq wrote:
>>
>> Take a look at this code snippet I found for the login page.
>>
>>
>> // activate login feature if script is activated and browser is supported
>> if ($.browser.msie && $.browser.version < 8) {
>> $('#browser-redirection').css('display', '');
>> } else {
>> $('.script-checking').css('display', '');
>> $('#warnings').css('display', 'none');
>> }
>>
>>
>> So my understanding is that the login feature is not getting activated at
>> all as JMeter does not run javascript.
>> Is that correct?
>> Is there any way for me to simulate a user logging in with this situation?
>>
>>
>>
>>
>>
>> On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
>>
>> >> . If the recorded requests have the same problems as your test plan did,
>> > which is fairly common when you have dynamic data and is not a good
>> > indicator.
>> >
>> >
>> >
>> > On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
>> > wrote:
>> >
>> >> If you use the Proxy setup, you can then just 'replay' the previous
>> >> requests and see if they have the same problem as you were
>> >> having. Basically, disable your test requests, and copy/paste the ones
>> >> from the Proxy recording in their place. Run the test using
>> >> the recorded requests, and watch the Tree Listener for the responses
>> from
>> >> the server. If the recorded requests have the same
>> >> problems as your test plan did, then you will definitely need to discuss
>> >> with your developers (maybe it's just a bug in their
>> >> code?). If the recorded proxy script works normally, then you have a
>> >> problem in your JMeter test plan setup - and you can use the
>> >> proxy requests to figure out what is missing from your test plan.
>> >>
>> >> --
>> >> Robin D. Wilson
>> >> Sr. Director of Web Development
>> >> KingsIsle Entertainment, Inc.
>> >> VOICE: 512-777-1861
>> >> http://www.kingsisle.com
>> >>
>> >>
>> >> -Original Message-
>> >> From: nmq [mailto:nmq0...@gmail.com]
>> >> Sent: Tuesday, June 11, 2013 3:31 PM
>> >> To: JMeter Users List
>> >> Subject: Re: Login failed - javascript
>> >>
>> >> I meant they're encoding the request using javascript. Should I have a
>> >> talk with the developers?
>> >> Problem is they're offshore
Re: Login failed - javascript
FYI! Deepak was correct. There's also a cookie being set.
I just used the script generated by BadBoy and it recorded the HTTP request
with a cookie value which is of course a static value.
So now I need to extract the cookie value using a regular expression and
then use it.
I'm going to try and figure out how to do this.
Thanks
Sam
On Wed, Jun 12, 2013 at 8:29 AM, nmq wrote:
> Thanks guys.
>
> I was able to log in finally. Tried a lot of stuff, but what worked was
> unchecking "redirect automatically" on the HTTP samplers. I would like to
> figure out why unchecking "redirect automatically" made a difference.
> Insights? Opinions?
>
> Thanks
> Sam
>
>
> On Tue, Jun 11, 2013 at 11:57 PM, Robin D. Wilson wrote:
>
>> By the way, this is where recording a login using the HTTP Proxy Recorder
>> would help up you figure this problem out.
>>
>> --
>> Robin D. Wilson
>> VOICE: 512-777-1861
>>
>>
>>
>> On Jun 11, 2013, at 10:54 PM, "Robin D. Wilson"
>> wrote:
>>
>> It appears to me that the way this works is to hide/unhide some elements
>> on the page using JavaScript. The way that would work is to hide an element
>> that says "you must enable JavaScript" and unhide an element that has the
>> login form on it.
>>
>> If that is the case, then you can just ignore the "you must enable
>> JavaScript" warning, and just submit the form anyway. The server has no way
>> to know whether the browser hid/un-hid anything, so if you submit the login
>> form it will assume you saw the login form.
>>
>> When you are looking in the tree listener, are you looking at the "text"
>> of the response, or are you looking at the rendered HTML? You really need
>> to look at the "text" since that's what JMeter actually sees. It may be a
>> "red herring" to assume that the JavaScript warning makes a difference
>> since you are looking at the response in a tool (the Tree Listener) that
>> doesn't execute the JavaScript, and never will.
>>
>> --
>> Robin D. Wilson
>> VOICE: 512-777-1861
>>
>>
>>
>> On Jun 11, 2013, at 9:41 PM, nmq wrote:
>>
>> Take a look at this code snippet I found for the login page.
>>
>>
>> // activate login feature if script is activated and browser is supported
>> if ($.browser.msie && $.browser.version < 8) {
>> $('#browser-redirection').css('display', '');
>> } else {
>> $('.script-checking').css('display', '');
>> $('#warnings').css('display', 'none');
>> }
>>
>>
>> So my understanding is that the login feature is not getting activated at
>> all as JMeter does not run javascript.
>> Is that correct?
>> Is there any way for me to simulate a user logging in with this situation?
>>
>>
>>
>>
>>
>> On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
>>
>> >> . If the recorded requests have the same problems as your test plan
>> did,
>> > which is fairly common when you have dynamic data and is not a good
>> > indicator.
>> >
>> >
>> >
>> > On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
>> > wrote:
>> >
>> >> If you use the Proxy setup, you can then just 'replay' the previous
>> >> requests and see if they have the same problem as you were
>> >> having. Basically, disable your test requests, and copy/paste the ones
>> >> from the Proxy recording in their place. Run the test using
>> >> the recorded requests, and watch the Tree Listener for the responses
>> from
>> >> the server. If the recorded requests have the same
>> >> problems as your test plan did, then you will definitely need to
>> discuss
>> >> with your developers (maybe it's just a bug in their
>> >> code?). If the recorded proxy script works normally, then you have a
>> >> problem in your JMeter test plan setup - and you can use the
>> >> proxy requests to figure out what is missing from your test plan.
>> >>
>> >> --
>> >> Robin D. Wilson
>> >> Sr. Director of Web Development
>> >> KingsIsle Entertainment, Inc.
>> >> VOICE: 512-777-1861
>> >> http://www.kingsisle.com
>> >>
>> >>
>> >> -Original Message-
>> >> From: nmq [mailto:nmq0...@gmail.com]
>> >> Sent:
Re: Login failed - javascript
Thanks guys.
I was able to log in finally. Tried a lot of stuff, but what worked was
unchecking "redirect automatically" on the HTTP samplers. I would like to
figure out why unchecking "redirect automatically" made a difference.
Insights? Opinions?
Thanks
Sam
On Tue, Jun 11, 2013 at 11:57 PM, Robin D. Wilson wrote:
> By the way, this is where recording a login using the HTTP Proxy Recorder
> would help up you figure this problem out.
>
> --
> Robin D. Wilson
> VOICE: 512-777-1861
>
>
>
> On Jun 11, 2013, at 10:54 PM, "Robin D. Wilson"
> wrote:
>
> It appears to me that the way this works is to hide/unhide some elements
> on the page using JavaScript. The way that would work is to hide an element
> that says "you must enable JavaScript" and unhide an element that has the
> login form on it.
>
> If that is the case, then you can just ignore the "you must enable
> JavaScript" warning, and just submit the form anyway. The server has no way
> to know whether the browser hid/un-hid anything, so if you submit the login
> form it will assume you saw the login form.
>
> When you are looking in the tree listener, are you looking at the "text"
> of the response, or are you looking at the rendered HTML? You really need
> to look at the "text" since that's what JMeter actually sees. It may be a
> "red herring" to assume that the JavaScript warning makes a difference
> since you are looking at the response in a tool (the Tree Listener) that
> doesn't execute the JavaScript, and never will.
>
> --
> Robin D. Wilson
> VOICE: 512-777-1861
>
>
>
> On Jun 11, 2013, at 9:41 PM, nmq wrote:
>
> Take a look at this code snippet I found for the login page.
>
>
> // activate login feature if script is activated and browser is supported
> if ($.browser.msie && $.browser.version < 8) {
> $('#browser-redirection').css('display', '');
> } else {
> $('.script-checking').css('display', '');
> $('#warnings').css('display', 'none');
> }
>
>
> So my understanding is that the login feature is not getting activated at
> all as JMeter does not run javascript.
> Is that correct?
> Is there any way for me to simulate a user logging in with this situation?
>
>
>
>
>
> On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
>
> >> . If the recorded requests have the same problems as your test plan did,
> > which is fairly common when you have dynamic data and is not a good
> > indicator.
> >
> >
> >
> > On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
> > wrote:
> >
> >> If you use the Proxy setup, you can then just 'replay' the previous
> >> requests and see if they have the same problem as you were
> >> having. Basically, disable your test requests, and copy/paste the ones
> >> from the Proxy recording in their place. Run the test using
> >> the recorded requests, and watch the Tree Listener for the responses
> from
> >> the server. If the recorded requests have the same
> >> problems as your test plan did, then you will definitely need to discuss
> >> with your developers (maybe it's just a bug in their
> >> code?). If the recorded proxy script works normally, then you have a
> >> problem in your JMeter test plan setup - and you can use the
> >> proxy requests to figure out what is missing from your test plan.
> >>
> >> --
> >> Robin D. Wilson
> >> Sr. Director of Web Development
> >> KingsIsle Entertainment, Inc.
> >> VOICE: 512-777-1861
> >> http://www.kingsisle.com
> >>
> >>
> >> -Original Message-
> >> From: nmq [mailto:nmq0...@gmail.com]
> >> Sent: Tuesday, June 11, 2013 3:31 PM
> >> To: JMeter Users List
> >> Subject: Re: Login failed - javascript
> >>
> >> I meant they're encoding the request using javascript. Should I have a
> >> talk with the developers?
> >> Problem is they're offshore *sigh*.
> >>
> >>
> >> On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote:
> >>
> >>> Hi Deepak
> >>>
> >>> Thanks for all that info. I installed fiddler quickly.
> >>>
> >>> This is what I got in request header:
> >>> /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is
> >>> significant OR I could be wrong. Correct me if I am.
> >>> It also says "response is encoded and may need to b
Re: Login failed - javascript
By the way, this is where recording a login using the HTTP Proxy Recorder would
help up you figure this problem out.
--
Robin D. Wilson
VOICE: 512-777-1861
On Jun 11, 2013, at 10:54 PM, "Robin D. Wilson" wrote:
It appears to me that the way this works is to hide/unhide some elements on the
page using JavaScript. The way that would work is to hide an element that says
"you must enable JavaScript" and unhide an element that has the login form on
it.
If that is the case, then you can just ignore the "you must enable JavaScript"
warning, and just submit the form anyway. The server has no way to know whether
the browser hid/un-hid anything, so if you submit the login form it will assume
you saw the login form.
When you are looking in the tree listener, are you looking at the "text" of the
response, or are you looking at the rendered HTML? You really need to look at
the "text" since that's what JMeter actually sees. It may be a "red herring" to
assume that the JavaScript warning makes a difference since you are looking at
the response in a tool (the Tree Listener) that doesn't execute the JavaScript,
and never will.
--
Robin D. Wilson
VOICE: 512-777-1861
On Jun 11, 2013, at 9:41 PM, nmq wrote:
Take a look at this code snippet I found for the login page.
// activate login feature if script is activated and browser is supported
if ($.browser.msie && $.browser.version < 8) {
$('#browser-redirection').css('display', '');
} else {
$('.script-checking').css('display', '');
$('#warnings').css('display', 'none');
}
So my understanding is that the login feature is not getting activated at
all as JMeter does not run javascript.
Is that correct?
Is there any way for me to simulate a user logging in with this situation?
On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
>> . If the recorded requests have the same problems as your test plan did,
> which is fairly common when you have dynamic data and is not a good
> indicator.
>
>
>
> On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
> wrote:
>
>> If you use the Proxy setup, you can then just 'replay' the previous
>> requests and see if they have the same problem as you were
>> having. Basically, disable your test requests, and copy/paste the ones
>> from the Proxy recording in their place. Run the test using
>> the recorded requests, and watch the Tree Listener for the responses from
>> the server. If the recorded requests have the same
>> problems as your test plan did, then you will definitely need to discuss
>> with your developers (maybe it's just a bug in their
>> code?). If the recorded proxy script works normally, then you have a
>> problem in your JMeter test plan setup - and you can use the
>> proxy requests to figure out what is missing from your test plan.
>>
>> --
>> Robin D. Wilson
>> Sr. Director of Web Development
>> KingsIsle Entertainment, Inc.
>> VOICE: 512-777-1861
>> http://www.kingsisle.com
>>
>>
>> -Original Message-
>> From: nmq [mailto:nmq0...@gmail.com]
>> Sent: Tuesday, June 11, 2013 3:31 PM
>> To: JMeter Users List
>> Subject: Re: Login failed - javascript
>>
>> I meant they're encoding the request using javascript. Should I have a
>> talk with the developers?
>> Problem is they're offshore *sigh*.
>>
>>
>> On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote:
>>
>>> Hi Deepak
>>>
>>> Thanks for all that info. I installed fiddler quickly.
>>>
>>> This is what I got in request header:
>>> /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is
>>> significant OR I could be wrong. Correct me if I am.
>>> It also says "response is encoded and may need to be decoded before
>>> inspection" when I clicked on Inspectors tab. Do you think this might
>>> be the problem? They're encoding the password using javascript? If
>>> yes, what can I do to bypass this?
>>>
>>>
>>> Hey Robin, I've done all of that. I used a tool called badboy to
>>> capture the script, so didn't need to use the proxy. I've tried both
>>> Firefox and Chrome strings for the user-agent in HTTP Header Manager.
>>> Everything was working fine before they deployed the current build
>> yesterday.
>>>
>>>
>>> Regards
>>> Sam
>>>
>>>
>>>
>>> On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson >> wrote:
>>>
>>>> First, this
Re: Login failed - javascript
It appears to me that the way this works is to hide/unhide some elements on the
page using JavaScript. The way that would work is to hide an element that says
"you must enable JavaScript" and unhide an element that has the login form on
it.
If that is the case, then you can just ignore the "you must enable JavaScript"
warning, and just submit the form anyway. The server has no way to know whether
the browser hid/un-hid anything, so if you submit the login form it will assume
you saw the login form.
When you are looking in the tree listener, are you looking at the "text" of the
response, or are you looking at the rendered HTML? You really need to look at
the "text" since that's what JMeter actually sees. It may be a "red herring" to
assume that the JavaScript warning makes a difference since you are looking at
the response in a tool (the Tree Listener) that doesn't execute the JavaScript,
and never will.
--
Robin D. Wilson
VOICE: 512-777-1861
On Jun 11, 2013, at 9:41 PM, nmq wrote:
Take a look at this code snippet I found for the login page.
// activate login feature if script is activated and browser is supported
if ($.browser.msie && $.browser.version < 8) {
$('#browser-redirection').css('display', '');
} else {
$('.script-checking').css('display', '');
$('#warnings').css('display', 'none');
}
So my understanding is that the login feature is not getting activated at
all as JMeter does not run javascript.
Is that correct?
Is there any way for me to simulate a user logging in with this situation?
On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
>> . If the recorded requests have the same problems as your test plan did,
> which is fairly common when you have dynamic data and is not a good
> indicator.
>
>
>
> On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
> wrote:
>
>> If you use the Proxy setup, you can then just 'replay' the previous
>> requests and see if they have the same problem as you were
>> having. Basically, disable your test requests, and copy/paste the ones
>> from the Proxy recording in their place. Run the test using
>> the recorded requests, and watch the Tree Listener for the responses from
>> the server. If the recorded requests have the same
>> problems as your test plan did, then you will definitely need to discuss
>> with your developers (maybe it's just a bug in their
>> code?). If the recorded proxy script works normally, then you have a
>> problem in your JMeter test plan setup - and you can use the
>> proxy requests to figure out what is missing from your test plan.
>>
>> --
>> Robin D. Wilson
>> Sr. Director of Web Development
>> KingsIsle Entertainment, Inc.
>> VOICE: 512-777-1861
>> http://www.kingsisle.com
>>
>>
>> -Original Message-
>> From: nmq [mailto:nmq0...@gmail.com]
>> Sent: Tuesday, June 11, 2013 3:31 PM
>> To: JMeter Users List
>> Subject: Re: Login failed - javascript
>>
>> I meant they're encoding the request using javascript. Should I have a
>> talk with the developers?
>> Problem is they're offshore *sigh*.
>>
>>
>> On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote:
>>
>>> Hi Deepak
>>>
>>> Thanks for all that info. I installed fiddler quickly.
>>>
>>> This is what I got in request header:
>>> /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is
>>> significant OR I could be wrong. Correct me if I am.
>>> It also says "response is encoded and may need to be decoded before
>>> inspection" when I clicked on Inspectors tab. Do you think this might
>>> be the problem? They're encoding the password using javascript? If
>>> yes, what can I do to bypass this?
>>>
>>>
>>> Hey Robin, I've done all of that. I used a tool called badboy to
>>> capture the script, so didn't need to use the proxy. I've tried both
>>> Firefox and Chrome strings for the user-agent in HTTP Header Manager.
>>> Everything was working fine before they deployed the current build
>> yesterday.
>>>
>>>
>>> Regards
>>> Sam
>>>
>>>
>>>
>>> On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson >> wrote:
>>>
>>>> First, this isn't really a "limitation" of JMeter, it is an artifact
>>>> of the way web sites work. Keep in mind, JMeter is designed to test
>>>> the 'server' part of the web system, bu
Re: Login failed - javascript
Take a look at this code snippet I found for the login page.
// activate login feature if script is activated and browser is supported
if ($.browser.msie && $.browser.version < 8) {
$('#browser-redirection').css('display', '');
} else {
$('.script-checking').css('display', '');
$('#warnings').css('display', 'none');
}
So my understanding is that the login feature is not getting activated at
all as JMeter does not run javascript.
Is that correct?
Is there any way for me to simulate a user logging in with this situation?
On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty wrote:
> >. If the recorded requests have the same problems as your test plan did,
> which is fairly common when you have dynamic data and is not a good
> indicator.
>
>
>
> On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson
> wrote:
>
> > If you use the Proxy setup, you can then just 'replay' the previous
> > requests and see if they have the same problem as you were
> > having. Basically, disable your test requests, and copy/paste the ones
> > from the Proxy recording in their place. Run the test using
> > the recorded requests, and watch the Tree Listener for the responses from
> > the server. If the recorded requests have the same
> > problems as your test plan did, then you will definitely need to discuss
> > with your developers (maybe it's just a bug in their
> > code?). If the recorded proxy script works normally, then you have a
> > problem in your JMeter test plan setup - and you can use the
> > proxy requests to figure out what is missing from your test plan.
> >
> > --
> > Robin D. Wilson
> > Sr. Director of Web Development
> > KingsIsle Entertainment, Inc.
> > VOICE: 512-777-1861
> > http://www.kingsisle.com
> >
> >
> > -Original Message-
> > From: nmq [mailto:nmq0...@gmail.com]
> > Sent: Tuesday, June 11, 2013 3:31 PM
> > To: JMeter Users List
> > Subject: Re: Login failed - javascript
> >
> > I meant they're encoding the request using javascript. Should I have a
> > talk with the developers?
> > Problem is they're offshore *sigh*.
> >
> >
> > On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote:
> >
> > > Hi Deepak
> > >
> > > Thanks for all that info. I installed fiddler quickly.
> > >
> > > This is what I got in request header:
> > > /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is
> > > significant OR I could be wrong. Correct me if I am.
> > > It also says "response is encoded and may need to be decoded before
> > > inspection" when I clicked on Inspectors tab. Do you think this might
> > > be the problem? They're encoding the password using javascript? If
> > > yes, what can I do to bypass this?
> > >
> > >
> > > Hey Robin, I've done all of that. I used a tool called badboy to
> > > capture the script, so didn't need to use the proxy. I've tried both
> > > Firefox and Chrome strings for the user-agent in HTTP Header Manager.
> > > Everything was working fine before they deployed the current build
> > yesterday.
> > >
> > >
> > > Regards
> > > Sam
> > >
> > >
> > >
> > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson > >wrote:
> > >
> > >> First, this isn't really a "limitation" of JMeter, it is an artifact
> > >> of the way web sites work. Keep in mind, JMeter is designed to test
> > >> the 'server' part of the web system, but web systems include the
> > >> 'browser' in the application logic (often times incorporating a lot
> > >> of logic in the JavaScript code that runs in the browser, or in other
> > >> coding systems such as Flash and Silverlight). You could call that a
> > >> 'limitation' of JMeter, but that would be like saying that a chainsaw
> > >> is limited because it can't be used as a good hammer.
> > >>
> > >> There are a couple of ways this is measured, depending on the site in
> > >> question. If it is coming from the server, it is probably looking at
> > >> a header in the request to figure out if you have JavaScript enabled.
> > >> Add an "HTTP Header Manager" element to your test plan, and set a
> > >> User-Agent value...
> > >>
> > >> We use the following User-Agent value:
> > >>
> >
Re: Login failed - javascript
>. If the recorded requests have the same problems as your test plan did, which is fairly common when you have dynamic data and is not a good indicator. On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson wrote: > If you use the Proxy setup, you can then just 'replay' the previous > requests and see if they have the same problem as you were > having. Basically, disable your test requests, and copy/paste the ones > from the Proxy recording in their place. Run the test using > the recorded requests, and watch the Tree Listener for the responses from > the server. If the recorded requests have the same > problems as your test plan did, then you will definitely need to discuss > with your developers (maybe it's just a bug in their > code?). If the recorded proxy script works normally, then you have a > problem in your JMeter test plan setup - and you can use the > proxy requests to figure out what is missing from your test plan. > > -- > Robin D. Wilson > Sr. Director of Web Development > KingsIsle Entertainment, Inc. > VOICE: 512-777-1861 > http://www.kingsisle.com > > > -Original Message- > From: nmq [mailto:nmq0...@gmail.com] > Sent: Tuesday, June 11, 2013 3:31 PM > To: JMeter Users List > Subject: Re: Login failed - javascript > > I meant they're encoding the request using javascript. Should I have a > talk with the developers? > Problem is they're offshore *sigh*. > > > On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote: > > > Hi Deepak > > > > Thanks for all that info. I installed fiddler quickly. > > > > This is what I got in request header: > > /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is > > significant OR I could be wrong. Correct me if I am. > > It also says "response is encoded and may need to be decoded before > > inspection" when I clicked on Inspectors tab. Do you think this might > > be the problem? They're encoding the password using javascript? If > > yes, what can I do to bypass this? > > > > > > Hey Robin, I've done all of that. I used a tool called badboy to > > capture the script, so didn't need to use the proxy. I've tried both > > Firefox and Chrome strings for the user-agent in HTTP Header Manager. > > Everything was working fine before they deployed the current build > yesterday. > > > > > > Regards > > Sam > > > > > > > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson >wrote: > > > >> First, this isn't really a "limitation" of JMeter, it is an artifact > >> of the way web sites work. Keep in mind, JMeter is designed to test > >> the 'server' part of the web system, but web systems include the > >> 'browser' in the application logic (often times incorporating a lot > >> of logic in the JavaScript code that runs in the browser, or in other > >> coding systems such as Flash and Silverlight). You could call that a > >> 'limitation' of JMeter, but that would be like saying that a chainsaw > >> is limited because it can't be used as a good hammer. > >> > >> There are a couple of ways this is measured, depending on the site in > >> question. If it is coming from the server, it is probably looking at > >> a header in the request to figure out if you have JavaScript enabled. > >> Add an "HTTP Header Manager" element to your test plan, and set a > >> User-Agent value... > >> > >> We use the following User-Agent value: > >> > >> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT > >> 6.1; WOW64; Trident/5.0) > >> > >> This essentially tells the server that you are making requests with > >> the > >> IE9.0 browser (which supports JavaScript by default). (NOTE: > >> we use this because it is still our most popular browser (actually, > >> that's not quite true - it is the most common version of the most > >> popular browser 'type' (IE)) - for users hitting our sites.) > >> > >> But if you have a different user population, you might prefer to use > >> Chrome or Firefox or Safari as your 'standard test' User-Agent. > >> You can look up their User-Agent strings here: > >> > >> http://www.useragentstring.com/pages/useragentstring.php > >> > >> If the HTTP Header Manager + User-Agent value configuration doesn't > >> work, you will need to figure out how the server is determining that > >> the browser supports JavaScript, and mim
RE: Login failed - javascript
If you use the Proxy setup, you can then just 'replay' the previous requests and see if they have the same problem as you were having. Basically, disable your test requests, and copy/paste the ones from the Proxy recording in their place. Run the test using the recorded requests, and watch the Tree Listener for the responses from the server. If the recorded requests have the same problems as your test plan did, then you will definitely need to discuss with your developers (maybe it's just a bug in their code?). If the recorded proxy script works normally, then you have a problem in your JMeter test plan setup - and you can use the proxy requests to figure out what is missing from your test plan. -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 http://www.kingsisle.com -Original Message- From: nmq [mailto:nmq0...@gmail.com] Sent: Tuesday, June 11, 2013 3:31 PM To: JMeter Users List Subject: Re: Login failed - javascript I meant they're encoding the request using javascript. Should I have a talk with the developers? Problem is they're offshore *sigh*. On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote: > Hi Deepak > > Thanks for all that info. I installed fiddler quickly. > > This is what I got in request header: > /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is > significant OR I could be wrong. Correct me if I am. > It also says "response is encoded and may need to be decoded before > inspection" when I clicked on Inspectors tab. Do you think this might > be the problem? They're encoding the password using javascript? If > yes, what can I do to bypass this? > > > Hey Robin, I've done all of that. I used a tool called badboy to > capture the script, so didn't need to use the proxy. I've tried both > Firefox and Chrome strings for the user-agent in HTTP Header Manager. > Everything was working fine before they deployed the current build yesterday. > > > Regards > Sam > > > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson wrote: > >> First, this isn't really a "limitation" of JMeter, it is an artifact >> of the way web sites work. Keep in mind, JMeter is designed to test >> the 'server' part of the web system, but web systems include the >> 'browser' in the application logic (often times incorporating a lot >> of logic in the JavaScript code that runs in the browser, or in other >> coding systems such as Flash and Silverlight). You could call that a >> 'limitation' of JMeter, but that would be like saying that a chainsaw >> is limited because it can't be used as a good hammer. >> >> There are a couple of ways this is measured, depending on the site in >> question. If it is coming from the server, it is probably looking at >> a header in the request to figure out if you have JavaScript enabled. >> Add an "HTTP Header Manager" element to your test plan, and set a >> User-Agent value... >> >> We use the following User-Agent value: >> >> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT >> 6.1; WOW64; Trident/5.0) >> >> This essentially tells the server that you are making requests with >> the >> IE9.0 browser (which supports JavaScript by default). (NOTE: >> we use this because it is still our most popular browser (actually, >> that's not quite true - it is the most common version of the most >> popular browser 'type' (IE)) - for users hitting our sites.) >> >> But if you have a different user population, you might prefer to use >> Chrome or Firefox or Safari as your 'standard test' User-Agent. >> You can look up their User-Agent strings here: >> >> http://www.useragentstring.com/pages/useragentstring.php >> >> If the HTTP Header Manager + User-Agent value configuration doesn't >> work, you will need to figure out how the server is determining that >> the browser supports JavaScript, and mimic that with your test. It is >> usually easier to setup the 'HTTP Proxy Server', and just collect a >> session from your browser than it is to try to figure it out manually >> though. >> >> To setup the proxy and capture a session: >> >> 1) Create a new Test Plan. >> 2) Right-Click on "Workbench" and select: >> >> Add->Non-Test Elements->HTTP Proxy Server >> >> 3) Make sure "Capture HTTP Headers" is checked >> 4) Click "Start" on the HTTP Proxy Server configuration page (at the >> bottom of the page) >> 5) In
Re: Login failed - javascript
no - a particular parameter may be encoded or encrypted or whatever - but you can find that out by the comparison . The message you are seeing in fiddler however is not related to this. Responses from the server can be chunked or gzipped and Fiddler is just telling you that. On Tue, Jun 11, 2013 at 1:30 PM, nmq wrote: > I meant they're encoding the request using javascript. Should I have a talk > with the developers? > Problem is they're offshore *sigh*. > > > On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote: > > > Hi Deepak > > > > Thanks for all that info. I installed fiddler quickly. > > > > This is what I got in request header: > > /UpdateCheck.aspx?isBeta=True HTTP/1.1 > > which I don't think is significant OR I could be wrong. Correct me if I > am. > > It also says "response is encoded and may need to be decoded before > > inspection" when I clicked on Inspectors tab. Do you think this might be > > the problem? They're encoding the password using javascript? If yes, what > > can I do to bypass this? > > > > > > Hey Robin, I've done all of that. I used a tool called badboy to capture > > the script, so didn't need to use the proxy. I've tried both Firefox and > > Chrome strings for the user-agent in HTTP Header Manager. Everything was > > working fine before they deployed the current build yesterday. > > > > > > Regards > > Sam > > > > > > > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson >wrote: > > > >> First, this isn't really a "limitation" of JMeter, it is an artifact of > >> the way web sites work. Keep in mind, JMeter is designed to > >> test the 'server' part of the web system, but web systems include the > >> 'browser' in the application logic (often times incorporating > >> a lot of logic in the JavaScript code that runs in the browser, or in > >> other coding systems such as Flash and Silverlight). You could > >> call that a 'limitation' of JMeter, but that would be like saying that a > >> chainsaw is limited because it can't be used as a good > >> hammer. > >> > >> There are a couple of ways this is measured, depending on the site in > >> question. If it is coming from the server, it is probably > >> looking at a header in the request to figure out if you have JavaScript > >> enabled. Add an "HTTP Header Manager" element to your test > >> plan, and set a User-Agent value... > >> > >> We use the following User-Agent value: > >> > >> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; > >> WOW64; Trident/5.0) > >> > >> This essentially tells the server that you are making requests with the > >> IE9.0 browser (which supports JavaScript by default). (NOTE: > >> we use this because it is still our most popular browser (actually, > >> that's not quite true - it is the most common version of the > >> most popular browser 'type' (IE)) - for users hitting our sites.) > >> > >> But if you have a different user population, you might prefer to use > >> Chrome or Firefox or Safari as your 'standard test' User-Agent. > >> You can look up their User-Agent strings here: > >> > >> http://www.useragentstring.com/pages/useragentstring.php > >> > >> If the HTTP Header Manager + User-Agent value configuration doesn't > work, > >> you will need to figure out how the server is determining > >> that the browser supports JavaScript, and mimic that with your test. It > >> is usually easier to setup the 'HTTP Proxy Server', and just > >> collect a session from your browser than it is to try to figure it out > >> manually though. > >> > >> To setup the proxy and capture a session: > >> > >> 1) Create a new Test Plan. > >> 2) Right-Click on "Workbench" and select: > >> > >> Add->Non-Test Elements->HTTP Proxy Server > >> > >> 3) Make sure "Capture HTTP Headers" is checked > >> 4) Click "Start" on the HTTP Proxy Server configuration page (at the > >> bottom of the page) > >> 5) In your browser, set your Proxy Server address to "localhost", and > use > >> the port specified in your HTTP Proxy Server configuration > >> (default is 8080). > >> 6) Visit your site, and perform some functions you want in your test. > >> > >> These should start to record your requests in the test plan, below the > >> workbench section. You can click on one of the requests and > >> see what the "HTTP Header Manager" looks like, and use that as your > >> default HTTP Header Manager for your tests. You can also see > >> what sort of interactions are taking place between the browser and the > >> server - some of which may be under-the-covers (hidden from > >> the user) and allowing the server to figure out whether the site > supports > >> JavaScript. > >> > >> -- > >> Robin D. Wilson > >> Sr. Director of Web Development > >> KingsIsle Entertainment, Inc. > >> VOICE: 512-777-1861 > >> http://www.kingsisle.com > >> > >> > >> -Original Message- > >> From: nmq [mailto:nmq0...@gmail.com] > >> Sent: Tuesday, June 11, 2013 2:41 PM > >> To: JMeter Users List > >> Subject: Login failed - javascript > >> > >> Hi
Re: Login failed - javascript
hi you cant look at a request in isolation , you have to look at the sequence of requests and compare them to JMeter The response isnt that important (this is just fiddler telling you that an encoding was used - you can change it so that it will show you the text) - usually the request and response headers are sufficient to tell you what the problem is - if the server gets exactly the same request (url, parameters, headers) it will send you exactly the same response so the response text usually isnt significant. regards deepak On Tue, Jun 11, 2013 at 1:27 PM, nmq wrote: > Hi Deepak > > Thanks for all that info. I installed fiddler quickly. > > This is what I got in request header: > /UpdateCheck.aspx?isBeta=True HTTP/1.1 > which I don't think is significant OR I could be wrong. Correct me if I am. > It also says "response is encoded and may need to be decoded before > inspection" when I clicked on Inspectors tab. Do you think this might be > the problem? They're encoding the password using javascript? If yes, what > can I do to bypass this? > > > Hey Robin, I've done all of that. I used a tool called badboy to capture > the script, so didn't need to use the proxy. I've tried both Firefox and > Chrome strings for the user-agent in HTTP Header Manager. Everything was > working fine before they deployed the current build yesterday. > > > Regards > Sam > > > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson > wrote: > > > First, this isn't really a "limitation" of JMeter, it is an artifact of > > the way web sites work. Keep in mind, JMeter is designed to > > test the 'server' part of the web system, but web systems include the > > 'browser' in the application logic (often times incorporating > > a lot of logic in the JavaScript code that runs in the browser, or in > > other coding systems such as Flash and Silverlight). You could > > call that a 'limitation' of JMeter, but that would be like saying that a > > chainsaw is limited because it can't be used as a good > > hammer. > > > > There are a couple of ways this is measured, depending on the site in > > question. If it is coming from the server, it is probably > > looking at a header in the request to figure out if you have JavaScript > > enabled. Add an "HTTP Header Manager" element to your test > > plan, and set a User-Agent value... > > > > We use the following User-Agent value: > > > > User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; > > WOW64; Trident/5.0) > > > > This essentially tells the server that you are making requests with the > > IE9.0 browser (which supports JavaScript by default). (NOTE: > > we use this because it is still our most popular browser (actually, > that's > > not quite true - it is the most common version of the > > most popular browser 'type' (IE)) - for users hitting our sites.) > > > > But if you have a different user population, you might prefer to use > > Chrome or Firefox or Safari as your 'standard test' User-Agent. > > You can look up their User-Agent strings here: > > > > http://www.useragentstring.com/pages/useragentstring.php > > > > If the HTTP Header Manager + User-Agent value configuration doesn't work, > > you will need to figure out how the server is determining > > that the browser supports JavaScript, and mimic that with your test. It > is > > usually easier to setup the 'HTTP Proxy Server', and just > > collect a session from your browser than it is to try to figure it out > > manually though. > > > > To setup the proxy and capture a session: > > > > 1) Create a new Test Plan. > > 2) Right-Click on "Workbench" and select: > > > > Add->Non-Test Elements->HTTP Proxy Server > > > > 3) Make sure "Capture HTTP Headers" is checked > > 4) Click "Start" on the HTTP Proxy Server configuration page (at the > > bottom of the page) > > 5) In your browser, set your Proxy Server address to "localhost", and use > > the port specified in your HTTP Proxy Server configuration > > (default is 8080). > > 6) Visit your site, and perform some functions you want in your test. > > > > These should start to record your requests in the test plan, below the > > workbench section. You can click on one of the requests and > > see what the "HTTP Header Manager" looks like, and use that as your > > default HTTP Header Manager for your tests. You can also see > > what sort of interactions are taking place between the browser and the > > server - some of which may be under-the-covers (hidden from > > the user) and allowing the server to figure out whether the site supports > > JavaScript. > > > > -- > > Robin D. Wilson > > Sr. Director of Web Development > > KingsIsle Entertainment, Inc. > > VOICE: 512-777-1861 > > http://www.kingsisle.com > > > > > > -Original Message- > > From: nmq [mailto:nmq0...@gmail.com] > > Sent: Tuesday, June 11, 2013 2:41 PM > > To: JMeter Users List > > Subject: Login failed - javascript > > > > Hi everyone > > > > I have run into an issue running my basic login sc
Re: Login failed - javascript
I meant they're encoding the request using javascript. Should I have a talk with the developers? Problem is they're offshore *sigh*. On Tue, Jun 11, 2013 at 4:27 PM, nmq wrote: > Hi Deepak > > Thanks for all that info. I installed fiddler quickly. > > This is what I got in request header: > /UpdateCheck.aspx?isBeta=True HTTP/1.1 > which I don't think is significant OR I could be wrong. Correct me if I am. > It also says "response is encoded and may need to be decoded before > inspection" when I clicked on Inspectors tab. Do you think this might be > the problem? They're encoding the password using javascript? If yes, what > can I do to bypass this? > > > Hey Robin, I've done all of that. I used a tool called badboy to capture > the script, so didn't need to use the proxy. I've tried both Firefox and > Chrome strings for the user-agent in HTTP Header Manager. Everything was > working fine before they deployed the current build yesterday. > > > Regards > Sam > > > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson wrote: > >> First, this isn't really a "limitation" of JMeter, it is an artifact of >> the way web sites work. Keep in mind, JMeter is designed to >> test the 'server' part of the web system, but web systems include the >> 'browser' in the application logic (often times incorporating >> a lot of logic in the JavaScript code that runs in the browser, or in >> other coding systems such as Flash and Silverlight). You could >> call that a 'limitation' of JMeter, but that would be like saying that a >> chainsaw is limited because it can't be used as a good >> hammer. >> >> There are a couple of ways this is measured, depending on the site in >> question. If it is coming from the server, it is probably >> looking at a header in the request to figure out if you have JavaScript >> enabled. Add an "HTTP Header Manager" element to your test >> plan, and set a User-Agent value... >> >> We use the following User-Agent value: >> >> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; >> WOW64; Trident/5.0) >> >> This essentially tells the server that you are making requests with the >> IE9.0 browser (which supports JavaScript by default). (NOTE: >> we use this because it is still our most popular browser (actually, >> that's not quite true - it is the most common version of the >> most popular browser 'type' (IE)) - for users hitting our sites.) >> >> But if you have a different user population, you might prefer to use >> Chrome or Firefox or Safari as your 'standard test' User-Agent. >> You can look up their User-Agent strings here: >> >> http://www.useragentstring.com/pages/useragentstring.php >> >> If the HTTP Header Manager + User-Agent value configuration doesn't work, >> you will need to figure out how the server is determining >> that the browser supports JavaScript, and mimic that with your test. It >> is usually easier to setup the 'HTTP Proxy Server', and just >> collect a session from your browser than it is to try to figure it out >> manually though. >> >> To setup the proxy and capture a session: >> >> 1) Create a new Test Plan. >> 2) Right-Click on "Workbench" and select: >> >> Add->Non-Test Elements->HTTP Proxy Server >> >> 3) Make sure "Capture HTTP Headers" is checked >> 4) Click "Start" on the HTTP Proxy Server configuration page (at the >> bottom of the page) >> 5) In your browser, set your Proxy Server address to "localhost", and use >> the port specified in your HTTP Proxy Server configuration >> (default is 8080). >> 6) Visit your site, and perform some functions you want in your test. >> >> These should start to record your requests in the test plan, below the >> workbench section. You can click on one of the requests and >> see what the "HTTP Header Manager" looks like, and use that as your >> default HTTP Header Manager for your tests. You can also see >> what sort of interactions are taking place between the browser and the >> server - some of which may be under-the-covers (hidden from >> the user) and allowing the server to figure out whether the site supports >> JavaScript. >> >> -- >> Robin D. Wilson >> Sr. Director of Web Development >> KingsIsle Entertainment, Inc. >> VOICE: 512-777-1861 >> http://www.kingsisle.com >> >> >> -Original Message- >> From: nmq [mailto:nmq0...@gmail.com] >> Sent: Tuesday, June 11, 2013 2:41 PM >> To: JMeter Users List >> Subject: Login failed - javascript >> >> Hi everyone >> >> I have run into an issue running my basic login script for the AUT. It >> was working fine till we got a new build this week. >> >> Now, I have been a functional tester my whole career. My company wanted >> me to do some performance test for them and I figured why >> the heck not. I'll learn along the way, so basically I'm a newbie in this >> area. >> >> Since JMeter is an open-source (translated: free of cost) tool that is >> supposedly powerful, we decided to use it (stupidly, without >> finding out its limitations). I've invested
Re: Login failed - javascript
Hi Deepak Thanks for all that info. I installed fiddler quickly. This is what I got in request header: /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is significant OR I could be wrong. Correct me if I am. It also says "response is encoded and may need to be decoded before inspection" when I clicked on Inspectors tab. Do you think this might be the problem? They're encoding the password using javascript? If yes, what can I do to bypass this? Hey Robin, I've done all of that. I used a tool called badboy to capture the script, so didn't need to use the proxy. I've tried both Firefox and Chrome strings for the user-agent in HTTP Header Manager. Everything was working fine before they deployed the current build yesterday. Regards Sam On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson wrote: > First, this isn't really a "limitation" of JMeter, it is an artifact of > the way web sites work. Keep in mind, JMeter is designed to > test the 'server' part of the web system, but web systems include the > 'browser' in the application logic (often times incorporating > a lot of logic in the JavaScript code that runs in the browser, or in > other coding systems such as Flash and Silverlight). You could > call that a 'limitation' of JMeter, but that would be like saying that a > chainsaw is limited because it can't be used as a good > hammer. > > There are a couple of ways this is measured, depending on the site in > question. If it is coming from the server, it is probably > looking at a header in the request to figure out if you have JavaScript > enabled. Add an "HTTP Header Manager" element to your test > plan, and set a User-Agent value... > > We use the following User-Agent value: > > User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; > WOW64; Trident/5.0) > > This essentially tells the server that you are making requests with the > IE9.0 browser (which supports JavaScript by default). (NOTE: > we use this because it is still our most popular browser (actually, that's > not quite true - it is the most common version of the > most popular browser 'type' (IE)) - for users hitting our sites.) > > But if you have a different user population, you might prefer to use > Chrome or Firefox or Safari as your 'standard test' User-Agent. > You can look up their User-Agent strings here: > > http://www.useragentstring.com/pages/useragentstring.php > > If the HTTP Header Manager + User-Agent value configuration doesn't work, > you will need to figure out how the server is determining > that the browser supports JavaScript, and mimic that with your test. It is > usually easier to setup the 'HTTP Proxy Server', and just > collect a session from your browser than it is to try to figure it out > manually though. > > To setup the proxy and capture a session: > > 1) Create a new Test Plan. > 2) Right-Click on "Workbench" and select: > > Add->Non-Test Elements->HTTP Proxy Server > > 3) Make sure "Capture HTTP Headers" is checked > 4) Click "Start" on the HTTP Proxy Server configuration page (at the > bottom of the page) > 5) In your browser, set your Proxy Server address to "localhost", and use > the port specified in your HTTP Proxy Server configuration > (default is 8080). > 6) Visit your site, and perform some functions you want in your test. > > These should start to record your requests in the test plan, below the > workbench section. You can click on one of the requests and > see what the "HTTP Header Manager" looks like, and use that as your > default HTTP Header Manager for your tests. You can also see > what sort of interactions are taking place between the browser and the > server - some of which may be under-the-covers (hidden from > the user) and allowing the server to figure out whether the site supports > JavaScript. > > -- > Robin D. Wilson > Sr. Director of Web Development > KingsIsle Entertainment, Inc. > VOICE: 512-777-1861 > http://www.kingsisle.com > > > -Original Message- > From: nmq [mailto:nmq0...@gmail.com] > Sent: Tuesday, June 11, 2013 2:41 PM > To: JMeter Users List > Subject: Login failed - javascript > > Hi everyone > > I have run into an issue running my basic login script for the AUT. It was > working fine till we got a new build this week. > > Now, I have been a functional tester my whole career. My company wanted me > to do some performance test for them and I figured why > the heck not. I'll learn along the way, so basically I'm a newbie in this > area. > > Since JMeter is an open-source (translated: free of cost) tool that is > supposedly powerful, we decided to use it (stupidly, without > finding out its limitations). I've invested quite some time in learning > the tool so I'm not ready to give up or switch to another. > I'm also not a programmer and don't have much info on java or javascript. > > Anyways, getting back to the point. I looked at the response in > ResultsTree in HTML format and this is the message I'm getting > on the Lo
RE: Login failed - javascript
First, this isn't really a "limitation" of JMeter, it is an artifact of the way web sites work. Keep in mind, JMeter is designed to test the 'server' part of the web system, but web systems include the 'browser' in the application logic (often times incorporating a lot of logic in the JavaScript code that runs in the browser, or in other coding systems such as Flash and Silverlight). You could call that a 'limitation' of JMeter, but that would be like saying that a chainsaw is limited because it can't be used as a good hammer. There are a couple of ways this is measured, depending on the site in question. If it is coming from the server, it is probably looking at a header in the request to figure out if you have JavaScript enabled. Add an "HTTP Header Manager" element to your test plan, and set a User-Agent value... We use the following User-Agent value: User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) This essentially tells the server that you are making requests with the IE9.0 browser (which supports JavaScript by default). (NOTE: we use this because it is still our most popular browser (actually, that's not quite true - it is the most common version of the most popular browser 'type' (IE)) - for users hitting our sites.) But if you have a different user population, you might prefer to use Chrome or Firefox or Safari as your 'standard test' User-Agent. You can look up their User-Agent strings here: http://www.useragentstring.com/pages/useragentstring.php If the HTTP Header Manager + User-Agent value configuration doesn't work, you will need to figure out how the server is determining that the browser supports JavaScript, and mimic that with your test. It is usually easier to setup the 'HTTP Proxy Server', and just collect a session from your browser than it is to try to figure it out manually though. To setup the proxy and capture a session: 1) Create a new Test Plan. 2) Right-Click on "Workbench" and select: Add->Non-Test Elements->HTTP Proxy Server 3) Make sure "Capture HTTP Headers" is checked 4) Click "Start" on the HTTP Proxy Server configuration page (at the bottom of the page) 5) In your browser, set your Proxy Server address to "localhost", and use the port specified in your HTTP Proxy Server configuration (default is 8080). 6) Visit your site, and perform some functions you want in your test. These should start to record your requests in the test plan, below the workbench section. You can click on one of the requests and see what the "HTTP Header Manager" looks like, and use that as your default HTTP Header Manager for your tests. You can also see what sort of interactions are taking place between the browser and the server - some of which may be under-the-covers (hidden from the user) and allowing the server to figure out whether the site supports JavaScript. -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 http://www.kingsisle.com -Original Message- From: nmq [mailto:nmq0...@gmail.com] Sent: Tuesday, June 11, 2013 2:41 PM To: JMeter Users List Subject: Login failed - javascript Hi everyone I have run into an issue running my basic login script for the AUT. It was working fine till we got a new build this week. Now, I have been a functional tester my whole career. My company wanted me to do some performance test for them and I figured why the heck not. I'll learn along the way, so basically I'm a newbie in this area. Since JMeter is an open-source (translated: free of cost) tool that is supposedly powerful, we decided to use it (stupidly, without finding out its limitations). I've invested quite some time in learning the tool so I'm not ready to give up or switch to another. I'm also not a programmer and don't have much info on java or javascript. Anyways, getting back to the point. I looked at the response in ResultsTree in HTML format and this is the message I'm getting on the Login page: "This website requires JavaScript Please activate JavaScript and press F5" HELP!! Regards Sam - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Login failed - javascript
Hi a. First you have to understand how your application works - i.e. how does it detect that the browser doesnt support javascript (there are some ways to do this - e.g. set a cookie in javascript or make an ajax call that dumps a value into session or generate a token in javascript etc) b. Then you simulate the same in JMeter. You usually debug this by running through the same steps on the browser but using a recording tool like fiddler/live http headers or whatever that captures the request and response headers. Then you compare the request and response in JMeter's view result tree. So if for e,g. a fresh(no cache) browser is sending some cookie (but there was no set-cookie , then its likely set from javascript and if your corresponding JMeter step doesn't send a cookie then you know where the issue is (note just an example - it depends on what your actual problem is) bottom line -You need to compare request / response of browser v/s Jmeter On Tue, Jun 11, 2013 at 12:40 PM, nmq wrote: > Hi everyone > > I have run into an issue running my basic login script for the AUT. It was > working fine till we got a new build this week. > > Now, I have been a functional tester my whole career. My company wanted me > to do some performance test for them and I figured why the heck not. I'll > learn along the way, so basically I'm a newbie in this area. > > Since JMeter is an open-source (translated: free of cost) tool that is > supposedly powerful, we decided to use it (stupidly, without finding out > its limitations). I've invested quite some time in learning the tool so I'm > not ready to give up or switch to another. I'm also not a programmer and > don't have much info on java or javascript. > > Anyways, getting back to the point. I looked at the response in > ResultsTree in HTML format and this is the message I'm getting on the Login > page: > > "This website requires JavaScript > Please activate JavaScript and press F5" > > HELP!! > > Regards > Sam >
