I'm working on automating the PUT API which expects file to be sent as InputStream. We used curl request to test this locally and now need to automate using RestAssured. I went through the documentation of RestAssured RequestSpecBuilder.setBody() which works only for POST methods and doesn't work for PUT.
Any pointers on how to upload file to PUT API using RestAssured would be helpful.
Below are details :
Curl command used curl -v --location --request PUT 'http://localhost:1080/update' "${HEADERS}" --upload-file <<FILE_PATH>>
API Definition :
#PUT
public Response updateResource(#Context final HttpServletRequest httpServletRequest,
#NotNull final InputStream inputRequestBody) {
// Do processing
}
given().multiPart() is used to upload a file.
The syntax will be similar to:
given().multipart("createJS", new File(D:\\Automation\\filepath"), "application/json")
You will need to change path and file type.
Related
Unable to send Custom headers for zap-api-scan.py, headers are declared in options.prop
I want to use zap to scan a rest API endpoint which requires Authorization & X-api-key header.
To specify the header, I have configured these in options.prop file.
But when I run
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-weekly zap-api-scan.py -t <API URL> -f openapi -z "-configfile /zap/wrk/options.prop"
I feel prop file is not getting picked. I get 401 error, as my Authorization token is not picked up.
Below is how my options.prop file looks
replacer.full_list(0).description=Authorization
replacer.full_list(0).enabled=true replacer.full_list(0).matchtype=REQ_HEADER
replacer.full_list(0).matchstr=Authorization
replacer.full_list(0).regex=false
replacer.full_list(0).replacement=<Token>
replacer.full_list(1).description=x-api-key
replacer.full_list(1).enabled=true
replacer.full_list(1).matchtype=REQ_HEADER
replacer.full_list(1).matchstr=x-api-key
replacer.full_list(1).regex=false
replacer.full_list(1).replacement=<Value>
I'm getting an Exception when running this, but Jenkins actually executes the requested action:
URL url = new URL("https://somehost.com/jenkins/quietDown");
HttpURLConnection c= (HttpURLConnection) url.openConnection();
c.setRequestMethod("POST");
c.setRequestProperty("Authorization", "Basic " + Base64.getEncoder().encodeToString(("user:apiToken").getBytes()));
c.getInputStream().close();
Exception:
Exception in thread "main" java.io.IOException: Server returned HTTP response code: 403 for URL: https://somehost.com/jenkins/
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at build.JenkinsClient.main(JenkinsClient.java:102)
Testing with Jenkins 2.164.3 and Java 8.
Setting this gets rid of the Exception:
connection.setInstanceFollowRedirects(false);
After hours I noticed how the stack trace contained a slightly different URL than the one I was posting to:
https://somehost.com/jenkins/
vs
https://somehost.com/jenkins/quietDown
It seems like Jenkins answers with a redirect (302 Found), which the HttUrlConnections follows by default to read from, which then for some reason caused that exception.
For the longest time, I tried to figure out a way to issue the POST request without calling connection.getInputStream(), but that seems to be the only call which actually triggers the request. If anyone knows a different way to issue a POST request with pure Java, please let me know.
I knew my URL and username:token stuff was correct because I tested with curl (which doesn't complain, even with the follow redirect option turned on):
curl -X POST https://somehost.com/jenkins/quietDown -u admin:token
curl -L -X POST https://somehost.com/jenkins/quietDown -u admin:token
I've been breaking my head over this for a few days now. This little sniplet is working fine (using Jersey 2.26-b03 on Tomcat).
#GET
#Path("/{code}")
public Response update(#PathParam("code") String code) {
System.out.println("!!!!!!!");
return Response.status(Response.Status.OK).build();
}
curl -i -X GET http://localhost:18270/nyx/rest/servervirtueel/SVM0000
HTTP/1.1 200 OK
Followed by a bunch of Jersey tracing I enabled. But if I only change the GET to a PUT (exactly the same method, just change the annotation):
#PUT
#Path("/{code}")
public Response update(#PathParam("code") String code) {
System.out.println("!!!!!!!");
return Response.status(Response.Status.OK).build();
}
curl -i -X PUT http://localhost:18270/nyx/rest/servervirtueel/SVM0000
HTTP/1.1 405 Method Not Allowed
Followed by HTML telling me that the "The specified HTTP method is not allowed for the requested resource". However, POST does work (changing the annotation again).
It turned out that the OWASP method whitelist valve was configured on Tomcat (Catalina) level to only allow GET and POST; this is a webapp that held only SOAP services until now. You do not see this in either web.xml's or server.xml, but it's in Catalina/localhost/webappname.xml.
I am using RESTEasy stack to implement a REST based client and server. I have a service which handles POST request, like below:
#POST
#Path("/this")
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public String testPost(#QueryParam("thing") String thing) {
...
}
When I call from Postman or REST client the following URI:
http://ip:port/base/this?thing={"id":"abc"}
I always get the error as
java.net.URISyntaxException: Illegal character in query at index (pointing to =)
What is the reason for this?
If you're trying to parse a POST request, you should use #FormParam instead of #QueryParam. Then, you can make the post request doing something like this (using curl)
curl -i -X POST -H "Content-Type: application/json" -d thing="{\"id\":\"abc\"}" http://ip:port/base/this
I have a working spring-mvc application with rest services and some rest-assured tests which are fine :
#Test
public void createFoobarFromScratchReturns201(){
expect().statusCode(201).given()
.queryParam("foo", generateFoo())
.queryParam("bar", generateBar())
.when().post("/foo/bar/");
}
=> OK
Then I implemented a digest authentication. Everything is working well, now I have to log in to use my services :
curl http://localhost:8089/foo/bar
=> HTTP ERROR 401, Full authentication is required to access this resource
curl http://localhost:8089/foo/bar --digest -u user_test:password
=> HTTP 201, CREATED
But when I try to upgrade my tests with the most obvious function, I still have a 401 error :
#Test
public void createFoobarFromScratchReturns201(){
expect().statusCode(201).given()
.auth().digest("user_test", "password") // Digest added here
.queryParam("foo", generateFoo())
.queryParam("bar", generateBar())
.when().post("/foo/bar/");
}
=> Expected status code <201> doesn't match actual status code <401>
I found some clues with the preemptive() function, but it seems to be only implemented for basic :
// Returns an AuthenticatedScheme and stores it into the general configuration
RestAssured.authentication = preemptive().basic("user_test", "password");
// Try a similar thing, but it didn't work :
RestAssured.authentication = RestAssured.digest("user_test", "password");
Currently, I am trying to achieve two things :
I need to upgrade a couple of my tests to support digest
I need to amend the #Before of the rest of my tests suites (whose are not related to auth issues), to be already logged in.
Any ideas or documentation ?
Try enabling support for cookies in the HTTP client embedded inside Rest Assured with:
RestAssuredConfig config = new RestAssuredConfig().httpClient(new HttpClientConfig().setParam(ClientPNames.COOKIE_POLICY, CookiePolicy.BEST_MATCH));
expect().statusCode(201).given()
.auth().digest("user_test", "password") // Digest added here
.config(config)
.queryParam("foo", generateFoo())
.queryParam("bar", generateBar())
.when().post("/foo/bar/");
The HTTP client (and therefore Rest Assured) supports digest authentication and the configuration of RestAssured using the digest method works well.