On 12 June 2013 13:29, nmq <nmq0...@gmail.com> 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 <rwils...@gmail.com>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" <rwils...@gmail.com>
>> 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 <nmq0...@gmail.com> wrote:
>>
>> Take a look at this code snippet I found for the login page.
>>
>> <script type="text/javascript">
>> // 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');
>> }
>> </script>
>>
>> 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 <shet...@gmail.com> 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 <rwils...@gmail.com>
>> > 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 <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
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>> >> For additional commands, e-mail: user-h...@jmeter.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
