jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nmq <nmq0...@gmail.com>
Subject Re: Login failed - javascript
Date Tue, 11 Jun 2013 20:30:34 GMT
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 <nmq0607@gmail.com> 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 <rwilson2@gmail.com>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:nmq0607@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-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message