Modify the request body with a FiddlerScript rule - fiddler

I have several rules for testing that modify responses from a server, but can't figure out how to modify the body of a POST request with a FiddlerScript rule. oSession.GetRequestBodyAsString() sounds useful, but I can't see any way to set the request body after I've modified it.
Am I missing something, or is there no way to do this?

var strBody=oSession.GetRequestBodyAsString();
strBody=strBody.replace("foo","bar");
oSession.utilSetRequestBody(strBody);
Use this code to do that, in this sample foo is replaced by bar.

Related

API Client testing tool for capturing requests

I need a tool which gives me a URL to make a HTTP request that will be recorded and it shows me what body was sent, which headers, which parameters, the method...
It's like something kind of opposite of Postman.
I tried to find such type of tool/service but didn't find any. If someone knows something similar, please let me know, thank you.
Actually, Postman has a feature which captures the request:
Enable it and just make the call to the set port (localhost:5555 by default) and it will be saved under the request history.

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

PUT Request showing in logs

Not sure if I'm missing something here, but every site on RESTful design states that updates should be done via a PUT request. I've been doing that, but noticed that the parameters are being put in the URL (unlike a POST request) which means they will show in the logs.
So if a user updates their password, the plain text password will show in the log. This doesn't seem right. What is the proper way to do this?
I don't think that it is required for PUT to have params in the URL to consider it as restful.
You should have the following or something similar
HTTPS PUT /users/<userid>/password
Body: {password: abcd}

jMeter signing URL and hash

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.

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.