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 <nmq0...@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 <rwils...@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: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 >> >> >
