Forum Discussion

sprice090161's avatar
sprice090161
Contributor
5 years ago
Solved

Has anyone actually been able to execute a POST or a GET Using AWS

I have spent at least a year working with Customer Support and Dev on the most basic of REST calls POST/GET to AWS. It does not work.  The first ticket that I entered I performed a sid by side test u...
  • richie's avatar
    richie
    5 years ago
    Hey sprice090161,

    I apologise if i misunderstood and went off at a tangent trying to help resolve your issue.....my ADHD tends to make for poor concentration occasionally.

    Short answer! :) Yes i was hitting AWS early last year.

    I think there's something really weird going on with your use case anyway, it looks like you have a couple of what appear to be additional commas at the ends of your SignedHeaders and Credential header values and a Content-Type: application/json header which would be superfluous i would've thought considering this is on a GET with no payload.

    Cheers!

    Rich
richie's avatar
richie
Community Hero
5 years ago
Hi sprice090161

What version of ReadyAPI! have you been using?

When you say youve been submitting calls to AWS, do you mean youve been submitting calls to an endpoint that is cloud hosted by AWS as opposed to Azure for example?
4.5 years ago i was hitting an MS Dynamics instance on AWS before it was migrated to Azure (i was using ReadyAPI! v1.9 and v2.0 at the time and Dev were using MUnit and Postman) and we never had problems and i was hitting another endpoint hosted by AWS in March last year with no problems.

You mention that providing both Postman and SoapUI with the same security credentials, Postman successfully submitted the request but SoapUI didnt because the dynamic generation of required value in the request's Authorization header wasn't working. But that isnt specific to AWS....its nothing to do with the endpoint whether its AWS, some other cloud hosting or even on premise hosting...thats ReadyAPI! behaviour.

Again i gotta ask...what version of ReadyAPI! have you been using?

Reason i ask is that i've been testing with ReadyAPI! constantly in the last 5 years. I remember i did have a problem for maybe 3months where there was a problem generating the Authorization header automatically, however i manually added in the Authorization header forcing the dynamic population and this worked. The issue i had was about 3.5 years ago (maybe ReadyAPI! v2.2?) ....i even submitted a post on the forum about it.
However, it's been years since i found the issue and i havent had the issue since.

In the last year i've had multiple different authorisation/authentication schemes...basic auth, certificates, OAuth v1.0, OAuth v2.0, etc. exercising both SOAP services and REST APIs across GET, PUT, POST, PATCH and DELETE methods and i havent had a problem with dynamic generation of a header in all that time.

You mention "apparently AWS published an issue for GETS, as they have no payloads. SoapUI doesn't handle this issue either.", what are you saying here?....are you saying that the auto generation of the Authorization header wasnt working for a GET request or are you saying that SoapUI doesnt allow you to submit payloads? I know that Postman does allow you to submit a GET request with a payload (or at least it did 6months ago), and ReadyAPI! doesnt, but that is actually correct according to a certain RFC (i cant remember which RFC says this). GET requests do not include payloads....if for any reason you want to pass a payload during a GET (yes it sounds weird but i have seen examples), then the RFC advice indicates you should use a POST.

I've had a number of issues with something initially working in Postman but not in ReadyAPI!, but i've always got things working in the end (using Fiddler to proxy the requests and posting queries on this forum). Postman abstracts out a lot of the hassle, but ReadyAPI! is far more feature rich, more complex allowing for greater control, and enabling more effective automation, etc. (Yes, i know what that sounds like, but no i dont work for Smartbear, but ive been testing a looooong time and believe ReadyAPI! is the most effective testing tool i ever used), hence the reason i think its worth putting the effort in getting it running in ReadyAPI!

Can you describe what auth you are using for your AWS endpoint along with clear instructions on how your Authorization header is supposed to be dynamically populated? The forum users may be able to help provide a workaround for your issue.

Cheers,

Rich
  • sonya_m's avatar
    sonya_m
    SmartBear Alumni (Retired)
    5 years ago

    Thank you richie!

    Hi sprice090161 , that would be great if you could expand your description a little. Please provide us with the additional info richie is requesting and the Community will try to help you further. Thank you.

    • sprice090161's avatar
      sprice090161
      Contributor
      5 years ago

      Here is the initial case that I submitted.  There was a defect found as I said before  pertaining the dynamic generation of the header value.

       

      From Customer Support

      "Development has created a defect of RIA-11463 for this issue as the x-amz-security-token header isn't signed in the AWS signature. "

       

      Case: 00352931
      Status: Researching
      Priority Level: High
      File Upload Link: http://smartbear.secure.force.com/support/WebToCaseFileUploadS3?caseId=5001O00001WBuWM

      Case Description:
      I want to execute a simple HTTP test step that accesses our API's in the AWS cloud. I manually load into our application and using th edev tools in chrome, I copy the current session AccessCode, SecretCode, and Security Token, along with region and service names, which are fixed.

      This works perfectly using "Postman". However it wont work in soapUI.

      From either the Resource Request for the http (defined via url) test step, or by adding an http test step to an existing test cases.

      The server url and endpoint are defined correctly.
      The AWS aut has been selected and defined with active credentials.
      Run the step and it fails as if the token has expired and yet they are new (We have a 1 hour timeout on the session token)

      <Fault xmlns="https://dev.api.newforma.cloud/v1/actionitems">
         <type>https://newforma.com/apierrors/bad_request</type>
         <title>The security token included in the request is invalid.</title>
         <message>The security token included in the request is invalid.</message>
         <requestId>ac2ab76c-8300-11e9-83a7-71b7c2a6db53</requestId>
      </Fault>

      Exact data as in the HTTP log file. The ready API log is empty

      Here is the Raw Request: as you can see the correct headers are all being generated.
      GET https://dev.api.newforma.cloud/v1/actionitems HTTP/1.1
      Accept-Encoding: gzip,deflate
      x-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
      Authorization: AWS4-HMAC-SHA256 Credential=ASIAWUJEERKJR6XIZ46F/20190530/us-east-1/execute-api/aws4_request, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=cdce4c69a83ae140baab47d6869a98fe014e33adb4c9515c2a31292d097ff02f
      x-amz-date: 20190530T173052Z
      content-type: application/json
      Content-Length: 0
      Host: dev.api.newforma.cloud
      Connection: Keep-Alive
      User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_181)
      *****************************************

      No there is yet another ticket because after this build was installed allowing me to perform a POST, I'm still not able to perform a get for the reason I mentioned earlier. You can search AWS for the bug that I later referenced in the subsequest ticket.
       
      I'm not asking you folks in the community to trouble shoot and solve the problem. I'm trying to understand if anyone has been successfull executing requests against there api's located up in the AWS cloud. 
       
       
       
      • richie's avatar
        richie
        Community Hero
        5 years ago
        Hey sprice090161,

        I apologise if i misunderstood and went off at a tangent trying to help resolve your issue.....my ADHD tends to make for poor concentration occasionally.

        Short answer! :) Yes i was hitting AWS early last year.

        I think there's something really weird going on with your use case anyway, it looks like you have a couple of what appear to be additional commas at the ends of your SignedHeaders and Credential header values and a Content-Type: application/json header which would be superfluous i would've thought considering this is on a GET with no payload.

        Cheers!

        Rich