jMeter signing URL and hash - rest

We are working on a time critical task and are required to write performance script for a REST WS using jMeter.
The REST API takes an auth header. This auth header has:
A signed URL (of the REST API itself).
A hash of everything sent in POST body.
We want a jMeter script so that it can:
Read the contents of the POST body from say an excel sheet or from a java method etc. as the content of post body has to change per login.
Create the hash of POST body everytime the content of body changes and use this hash in the auth header.
Sign the URL and use it in auth header.
My questions are:
Is all the above possible to achieve? This is the minimum i want to know so that I know if I have to spend any more time on this.
What is the best way to do this?
I am assuming that the content of POST body and auth header both can be dynamic. Is this correct? If not, we cannot write this script at all.
The only jMeter i know is what is here in the comment. It would be impossible to get all my answers in the given time.
Any answers, help, pointers would be helpful.
Appreciate you reading this - thanks in advance.

Yes, possible. We have done similar things.
Two possible options are:
use a beanshell pre-processor
use a custom function
We opted for the latter as it used memory better
and 3. Yes, you can pass in vars to make each request different. One way to source data is using a CSV Data Config control.

Related

Node-Red HTTP Input verify json

this might be a stupid question but I was unable to find a solution, also no luck with search.
My Node-Red flow gets triggered by a HTTP Input because I want to create a REST Webservice. It works fine so far but I wonder how to verify the content someone send to me.
As I see right now, I can pass any kind of content. There is no verification if the content matches to the content I want as input.
If I set content-type to application/json, it only accepts json data. That's great but I also want to ensure, users can post only a specific json string.
If someone sends data I'm unable to proceed (not the json object I expected), I want to send HTTP 400 as response.
I'm pretty new to Node-Red and also to json. I'm more an old-school programmer using classic webservices and soap. What I'm missing is some kind of WSDL (not sure if it exists when using REST) and some kind of payload validation.
It would be great if someone can point me the way to go.
Best regards
Patrick
There are some nodes available for doing schema validation on JSON objects.
For example, node-red-contrib-json-schema-validator - which uses ajv as the validation engine under the covers. Unfortunately this node doesn't come with much in the way of help. Essentially it lets you provide your schema and if a message fails to validate, it logs an error which can be handled with a Catch node if you want.
I found the issue. It was too bad.
I just forgotten to set HTTP Header content-type to application/json.
node-red-contrib-json-schema-validator works like a charm if content type is set corret

Is it possible to change/modify properties of a CR using OSLC_CM?

Is it possible to modify a property of a change request by using the OSLC-CM REST API of a change management system. The system that I'm trying to achieve that is Rational Change.
I can browse and query via the REST API, but to modify anything I need to resort to command line which is rather slow.
Is there a way?
BR,
Pawel
To update resources using the OSLC-CM REST API you simply just can use HTTP PUT. In order to do this, you'll first need the URL of the Change Request.
The steps to achieve this (using any HTTP client) are:
acquire URL for Change Request (usually done by query, or stored reference, etc)
Perform an HTTP GET on that URL, specifying a format for use in editing. This is done using 'Accept' header, some typical values would be 'application/xml', 'application/json' or 'application/rdf+xml'.
Note, it is a good idea to set the header 'OSLC-Core-Verson: 2.0' as well to ensure you are working with the 2.0 formats.
Once you have fetched the resource, modify the property to the value you want.
Using HTTP PUT, send the modified resource in the content body to the same URL you fetched the resource from.
Additionally you will most likely need to pass along some additional headers to help the server detect any possible conflict.
You should get back a 200 (OK) or 204 (No content) response on success.
An optimization would be to do the same steps as above but only request the properties of interest and only send them by using the selective properties feature of OSLC.
So I've finally got it working with some help from googlegroups
To recap what I've done so that someone else might benefit too (I really have searched for it and the IBM documentation is as in most of the cases not helping):
So to modify PR/CR' implement_actual_effort attribute on the Rational Change server the following procedure was successful (using Firefox REST plugin):
1. In Headers set: Accept to application/xml, Content-Type to application/xml
Put the oslc address of the cr i URL in my case it was:
http://[IP:PORT]/change/oslc/db/[DB hex ID]/role/User/cr/[web_encoded_name_of_the_CR]?oslc_cm.properties=change:implement_actual_effort
(note in browser http://[IP:PORT]/change/oslc/db/[DB hex ID]/role/User/cr/[web_encoded_name_of_the_CR] will open change page of the CR/PR)
In REST client set Method to GET and press SEND
Click on the Response Body (RAW), copy xml Body
Change Method to PUT, change the value of the attribute (in the xml in Body window)
Press SEND
Attribute should have been changed right now, and the response should be similiar to what you've sent, with the attribute showing the change.
Note that to change an attribute (called property from oslc point of view) one has to provide ?oslc_cm.properties=[properties delimited with comma]
and in the request body xml the same properties have to be present, if I remember correctly if the property isn't mentioned in the xml it will be set to default
I hope this helps someone
BR,
Pawel

How to reproduce a request via cURL

I want to capture how parameters are being sent. Usually what I do is to make a request and check on Firebug's params tab what are the parameters sent. However, when I try to do this on the following site (http://www.infraero.gov.br/voos/index_2.aspx), it doesn't work - I can't see what are the parameters in order to repeat this request using curl. How can I get it? I'm not sure but I think that cookies are being used.
EDIT
I was able to get the request content, but couldn't understand it. It seems it uses javascript to generate the proper request. How can I reproduce this request via cURL?
Did you see this previous question cURL post data to asp.net page ? That might answer the question right there (all I did was search "ASP.NET cURL"). And this one: Unable to load ASP.NET page using Python urllib2 talks about Python, but it approaches it in a way that should translate to cURL.
But for my $0.02, I wouldn't bother trying to untangle ASP.NET's and __VIEWSTATE and javascript. Is it an absolute requirement that you use cURL?
I think you would be better off using a client that works more like a real browser and understands javascript. That's a bit of work, but it isn't as bad as it sounds. I've done this before with http://watirwebdriver.com/ and a short Ruby script. Here's how to do it with Python and Mechanize (this is probably a bit more lightweight).
http://phantomjs.org/ is another option that you script using javascript. If you Google "Scraping ASP.NET" you will see that this is a common problem.
You didn't say how you want it done, but you can send the request with curl simply with curl -d name1=contents1&name2=contents2 [TARGETURL] etc.
Note that you probably first need to fetch the main page and extract the "__VIEWSTATE" form field and submit back that (VERY huge) contents to get your submission accepted.

iOS Development: When making a POST request, does it really matter if I include parameters in the URL?

I'm using the ASIHTTPRequest lib in my iOS app for making REST requests to a web app. I'm doing my best to use the correct verbs (GET, POST, PUT, DELETE) when making the various requests, but when making a POST request, I'm not sure I understand why it matters if I include the parameters in the POST request or in the URL. It works both ways, so why should I include the parameters in the POST request instead of just including them in the URL? As I understand it, the only reason for include the parameters in a POST request is to keep them from being visible in the URL in case someone is looking over your shoulder, or something like that. But if I'm making a POST request from my iOS app and there's no browser involved, then does it really matter which way I do it?
Thanks so much for your wisdom, I'm still learning!
When using a POST request, it is good practice to put the parameters in the data instead of the URL. In your case, it works to put it in the URL, but this isn't always true. Some scripts will expect the parameters to be in a specific place and not find them if they aren't there. As for what POST is good for, it allows you to send more data. The URL is limited to a length of 255 characters, so you need to use some other method if you want to send more data than that. The data in a POST request also doesn't need to be encoded to be compatible with the URL specification.
As I understand it, the only reason for include the parameters in a POST request is to keep them from being visible in the URL in case someone is looking over your shoulder, or something like that.
You misunderstand it.
There are other issues. If your site makes changes to data based off a GET request, it's possible that spambots, search engines, browser prefetchers, and other automated tools will trigger potentially destructive data changes.
If the endpoint isn't under your control, it's entirely possible that it won't even accept the parameters as GET parameters. Most APIs require proper usage of the GET vs. POST verbs.

Place API key in Headers or URL

I'm designing a public API to my company's data. We want application developers to sign up for an API key so that we can monitor use and overuse.
Since the API is REST, my initial thought is to put this key in a custom header. This is how I've seen Google, Amazon, and Yahoo do it. My boss, on the other hand, thinks the API is easier to use if the key becomes merely a part of the URL, etc. "http://api.domain.tld/longapikey1234/resource". I guess there is something to be said for that, but it violates the principle of the URL as a simple address of what you want, and not how or why you want it.
Would you find it logical to put the key in the URL? Or would you rather not have to manually set HTTP headers if writing a simple javascript frontend to some data?
It should be put in the HTTP Authorization header. The spec is here https://www.rfc-editor.org/rfc/rfc7235
If you want an argument that might appeal to a boss: Think about what a URL is. URLs are public. People copy and paste them. They share them, they put them on advertisements. Nothing prevents someone (knowingly or not) from mailing that URL around for other people to use. If your API key is in that URL, everybody has it.
It is better to use API Key in header, not in URL.
URLs are saved in browser's history if it is tried from browser. It is very rare scenario. But problem comes when the backend server logs all URLs. It might expose the API key.
In two ways, you can use API Key in header
Basic Authorization:
Example from stripe:
curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:
curl uses the -u flag to pass basic auth credentials (adding a colon after your API key will prevent it from asking you for a password).
Custom Header
curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users
passing api key in parameters makes it difficult for clients to keep their APIkeys secret, they tend to leak keys on a regular basis.
A better approach is to pass it in header of request url.you can set user-key header in your code .
For testing your request Url you can use Postman app in google chrome by setting user-key header to your api-key.
I would not put the key in the url, as it does violate this loose 'standard' that is REST. However, if you did, I would place it in the 'user' portion of the url.
eg: http://me#example.com/myresource/myid
This way it can also be passed as headers with basic-auth.