jmeter - Authorization header goes missing - jmeter

I have a fairly simple jmeter script for our site. As part of the flow through the site, I use our API in order to update the user's application.
The API uses OAuth authentication, which I'm familiar with using our own proprietary testing tool.
First I get a auth token via a call to our authorization endpoint. This returns a bit of JSON like this:
{"access_token":"a really long auth token string"}
In my script I use a regex to capture this token string. As part of investigating this problem, I've used a Debug PostProcessor to check that I get the correct string out, which I do. It's saved as variable 'authToken'.
In the very next step in the script, I add a header via a HTTP Header Manager, like so:
I know this header is correct as we have many instances of it in our API tests.
The relevant part of the script looks like this:
Each time I run the script however, the step that uses the token/header returns a 401 unauthorized.
I've tested the actual URL and header in a Chrome plugin and the call works as expected.
In the 'View Results Tree' listener, there is no evidence at all that the Authorization header is set at all. I've tried hard-coding an auth token but no joy - it still doesn't seem to be part of the request.
From the results tree, the request looks like this:
POST <correct URL>
POST data:{"id":"<item id>"}
Cookie Data: SessionProxyFilter_SessionId=<stuff>; sessionToken=<stuff>
Request Headers:
Content-Length: 52
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36
Connection: keep-alive
Content-Type: application/json
The results tree also shows no redirects.
I've tried the solutions here and here but neither of these worked.
Oddly, I'm almost certain that this worked about a month ago and as far as I can tell nothing has changed on the machine, in the script or with the jmeter installation. Obviously one of these is not true but I'm at my wit's end.

Another member of my team answered this for me and it's fairly simple. I just needed to set the 'Implementation' for the problem step to 'HttpClient4'.

Related

Ruby HTTP request always returns 403 response (too many requests). Works in Postman/browser

I am trying to write a simple function which would easily extract the contact information from a classified listing.
Background
The URL I'm looking at is
https://www.idealista.pt/imovel/27542922/
Looking through the developer tools in Chrome, I see that it makes a GET request to this URL. https://www.idealista.pt/pt/ajax/listingController/adContactInfoForListing.ajax?adId=27542922
If I make a GET request in Postman or just copy the second URL into Chrome I get a JSON containing various details.
My code
(Ruby)
uri = URI('https://www.idealista.pt/pt/ajax/listingController/adContactInfoForListing.ajax?adId=27542922')
foo = Net::HTTP.get(uri)
JSON.parse(foo)
The problem
The response is a 403 with a body saying that the system has detected that many requests have been made in a short period of time.
I can replicate this in Postman by doing seven or eight consecutive requests, but then if I wait a minute or two before trying again I get back to seeing the JSON.
Through Ruby it happens straight away.
What I've tried
I've tried copying some or all of the temporary headers created by Postman into my request in Ruby but I still get the same error or 404
User-Agent - PostmanRuntime/7.22.0
Accept - */*
Cache-Control - no-cache
Postman-Token - 6c68a9eb-83d5-4724-9f41-3fc51971db9f
Host - www.idealista.pt
Accept-Encoding - gzip, deflate, br
Cookie - userUUID=c017919a-6115-4905-95b3-5d949c6fb447; _pxhd=34ed938caca242bf6050147e1514cda07b704cc7681245a4beec5a64e0a5cf66:d4f21381-522a-11ea-a954-6f59910ff05b; SESSION=887b6dbc-78a4-4abd-9600-7ce401507331; WID=15a353ca7aab3446|XlEN6|XlEN4
Connection - keep-alive
you have to use a proxy, and chanfe the ip

Kibana String URL image template authentication

I am trying to work out whether it is possible to attach authentication, or make kibana send some sort of authentication with URL templates for field formatters in kibana.
Field formatters are found in:
Management -> Kibana -> Indices -> INDEX_NAME -> Field.
It is possible to display images on URLs with this. For this purpose, I have configured my URL template to be something among the lines of:
localhost:8080/resolve/{imageId}
The imageId is provided via the {{value}} variable and this works all fine.
now, the server running the image resolver has access to data beyond the scope of the image. I would like to add some authentication to the request coming in from Kibana. I have printed available headers and only gotten this:
{host=[localhost:8082], connection=[keep-alive], user-agent=[Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36], accept=[image/webp,image/apng,image/*,*/*;q=0.8], referer=[http://localhost:5601/app/kibana], accept-encoding=[gzip, deflate, br], accept-language=[en-GB,en;q=0.9,de-DE;q=0.8,de;q=0.7,en-US;q=0.6], cookie=[JSESSIONID.1f47f03c=node01x3mhn2jmd7g4qby84ryfcxmd1.node0; screenResolution=1920x1080; JSESSIONID.d86b4be4=node01gzefm5lc0i3c9itul3p0zoil1.node0; JSESSIONID.9211a7ee=node01v32dtus1uphtcvg72es74h681.node0]}
I can't find any basic authentication in there that I can take advantage of. I am not sure if the cookies can be used to resolve the authentication in a way?
My question is: Can I send basic authentication of the logged in user as part of my request? If so, how?
I realise this is not too much to go on. I am attaching a screenshot for hopefully a little more clarity.
I asked this on the elastic board as well who informed me of:
The cookies won't be sent to the third-party because of the same
origin restrictions that browsers put in place. Its not possible.
https://discuss.elastic.co/t/kibana-string-url-image-template-authentication/165786/2
Thanks!

Cloudflare identifying CURL

So I'm trying to create some scripts that have to run on a particular site protected by CloudFlare. I am getting one odd situation though:
Whenever I send a cURL request with the command line to that particular website (just a GET request), it reports a 503.
When I do the same request with a Firefox RESTED client, it reports a 200. - Running it in my browser executes the javascript protection as expected (so a 200 as well)
What can possibly be the trick to identifying a CURL vs a Firefox RESTED client-request, that both seem to do the exact same thing?
I'm using:
same IP
same User-Agent (in fact I tried mocking over 7 headers that my regular browser sends too, including Accept-Language Accept-Encoding and more)
Apparently when using the RESTED Firefox add-on, it uses all cookies that are currently in your firefox browser as well. One of these cookies identified my RESTED client as being valid

JMeter different results during replay of test

I have a strange problem with JMeter.
I've made recording of some sort of web application without any problems. Problem appears during playback of test.
For some reason I receive different results during playback than during recording.
When I compare Http Request made during recording and playback I don't see a single difference (except for some security token which I'm extracting from earlier requests and passing as parameter).
To be more exact during recording I receive a response with a big body (>5kB), and during playback body of response is empty. Response code is 200 (OK).
This body contains crucial data from database, so I'm afraid that measurement made by this JMeter script will not reflect actual behavior of application, simply I will not measure what I really need.
Now my questions:
is there some tool or JMeter plug-in which will allow more effectively see contents of HTTP requests and its responses? It would be great If I could compare of requests made during recording and playback. So far I used two listeners: "View Results Tree". I've sandwiched between them to compare request from recording and playback.
is there some known bug in JMeter which could explain the difference? For example something related to recording process?
Here is example of request:
POST http://10.133.27.81:8080/c/portal/render_portlet
POST data:
p_l_id=69210&p_p_id=blank_WAR_Blank_INSTANCE_iNM3&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2
[no cookies]
Request Headers:
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Accept-Language: pl
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
csrf_token: 1GXK-0QD7-GFPJ-JLDG-JP2G-J390-BFLG-7LL7
Pragma: no-cache
Method: POST /c/portal/render_portlet HTTP/1.1
X-Requested-With: OWASP CSRFGuard Project
Referer: http://10.133.27.81:8080/group/bou
Accept-Encoding: gzip, deflate
Content-Length: 143
Host: 10.133.27.81:8080
Update: to make sure which headers or parameters are constant I made 4 recordings of same test case during different sessions and compared them, so I'm quite sure that only csrf_token has to be field with value fetched from other request. I've added debug sampler to verify that this value is fetched properly.
Update 2: Problem found.
There where two problems:
There is a bug in JMeter when you do a search (Ctrl-F) it searches the whole project except for HTTP Header Menagers and my request contained csrf_token inside of header (I detected that before posting this question). Making a search in xml using text editor was good workaround for that.
when I try to find source of problems, before I've found problem number one, I've added a new problem by removing a HTTP Cookie Manager (I'm blaming myself and IE for this).
Generally changing Internet Explorer to FireFox with HttpFox add-on help to spot the problem.
Thanks everyone for support.
Marek
Response code 200 doesn't have to mean that everything went well at the application level.
To find out more details you can use Debug sampler and Debug PostProcessor.
Example here.
Your issue comes certainly from a missing dynamic request parameter that you didn't compute.
Look for example at csrf_token header Did you make it variable? Or do you transmit its initial recorded valur, but also at any parameter that contains some hashdata or numeric data referencing some content that does not exist in your page or request.
For example col pos I see p_p_col_id and related parameters, are you sure they reference something in your replay.
There is really very little chance of a JMeter bug in this case.

Different range request response in Firefox and Chrome

I am currently testing some JavaScript that makes a GET request (ie. XMLHttpRequest with "get") with a Range header. Because the request is cross-domain, I'm implementing access control headers in the response as described here:
https://developer.mozilla.org/En/HTTP_access_control#Preflighted_requests
What's confusing me however is that my current server setup is working in Chrome but not in Firefox. Specifically, when I run the JavaScript in Chrome I'm getting back a chunk of the requested data, just like I want. In Firefox however I'm getting error code 501 on request method OPTIONS
At first that seems like the OPTIONS request method needs to be handled by the server, but that works in Chrome so it looks like this is a red herring and something else is wrong. Currently the following response headers are implemented, perhaps this is where the problem lies:
Access-Control-Allow-Headers: Range
Access-Control-Allow-Origin: *
Anyone have any insight in what I need to do? Do Chrome and Firefox handle cross-domain restrictions differently?

Resources