Amplify-js: Cannot get API.get to work

[marioskonstantinou]

Hello,

I'm trying to use API.get and pass queryStringParameters in the request so these params can be accessed from Lambda function's 'event' but this doesn't seem to work.

    const val1 = 'test123';
    const val2 = 'test123';

    let myInit = {
        'queryStringParameters': {
            'key1': val1,
            'key2': val2
        },
        headers: {
            'Accept': 'application/json',
            'Content-Type': 'application/json',
        }
    };

    return API.get(apiName, path, myInit).then(data => {
        return data;
    }).catch(err => console.log('error.', err));

Notes:

1. I've added the query params in Api Gateway method (URL Query String Parameters)
2. In Lambda function's logs i can see queryStringParameters: null,
3. API Gateway Integration request details (Use Lambda Proxy integration is enabled)
   
4. I've tried adding the query params as part of path as abc?key1=val1&key2=val2 etc. but didn't work as well
5. API.post works good (when passing the params in body

Let me know if you need more details

Thanks in advance.

[powerful23]

@marioskonstantinou did you use mobile hub and awsmobile cli to create the Api and lambda functions?
Also it seems like we haven't supported this feature yet.

[marioskonstantinou]

@powerful23 I'm using mobile hub with API Gateway and Lambda functions yes. What is not supported ? API.get or passing query parameters?

[powerful23]

@marioskonstantinou passing query parameters

[marioskonstantinou]

@powerful23 Any plans on releasing this anytime soon? It's quite an important feature of the API

[mlabieniec]

@marioskonstantinou did you use the cli to init your project? i.e. awsmobile init or did you use Mobile Hub console and create your lambda function yourself? The reason i ask is because the awsmobile cli provides your lambda sample with the express framework which requires you to do a few things to receive the queryStringParameters, see here for example:
https://github.com/awslabs/aws-serverless-express#getting-the-api-gateway-event-object

[marioskonstantinou]

@mlabieniec I've created a new project through Mobile Hub along with Cloud Logic (API, Lambda functions etc.). Then i've linked (with the awsmobile cli commands) my (existing) react-native project with the project i've created in Mobile Hub.

[lichao0817]

@marioskonstantinou I have problem with passing the query parameters as well. I think the only workaround we can do is to dump everything into the url.

[marioskonstantinou]

@lichao0817 I've tried that already and it didn't work. If you have a working example, would u mind sharing it here?

[lichao0817]

@marioskonstantinou suppose that your path is const path = '/users';, if you want to include a param called email you simply append the param to the path. Now it becomes
const path = '/[email protected]';

[chapeljuice]

Thanks @lichao0817 for that work around ... I can't believe the queryStringParameters object isn't supported ... kind of important to be able to send parameters easily via a GET.

[chapeljuice]

@marioskonstantinou I have a React Native example here that should work until queryStringParameters is supported:

const apiName = 'http://myendpoint.com'
const path = `/my/path?param1=${value1}&param2=${value2}`
API.get(apiName, path)
    .then((response) => {
        resolve(response)
    },
    (err) => {
        console.log('err resp', err)
        resolve(err)
    })

[chapeljuice]

Eh, for anyone who's still following (@lichao0817 @marioskonstantinou) I may have spoke too soon ... now I'm getting the error about the request signature calculation being off. :(

[chapeljuice]

Okay so a colleague of mine figured out that the parameter values need to be URL encoded for this to work. I had a colon (:) in one of my values which resulted in me getting that signature calculation error.

Once I url encoded the colon (to %3A), the request returned a successful response.

Hope this helps anyone!

[vadiraja]

I am also getting Invalid Signature error with url query string parameters. No error if I pass queryString as Init {} options. But I don't get these query string in lambda functions (via APIG->Lambda Integration)

[nuttmeister]

Having this problem as well, is there anyway to get this working?
If I add the query string to the path I always get an signature error, regardless of if I urlencode it or not.

[chapeljuice]

@nuttmeister do you have the latest release? Try that if not.

[nuttmeister]

@chapeljuice yes, I'm using version 0.2.7.

None of the below works (it's against api-gw with lambda proxy).
Option 1 results in queryStrings being null in the lambda proxy.
Option 2 results in a signature error.

Option 1 (tried options both as object and JSON):
let options = {
"queryStringParameters": { "filter": "1234" }
}
API.get(endpoint, "/path", options)

Option 2 (tried with encodeURI() and without):
API.get(endpoint, "/path?filter=1234")

[nuttmeister]

I know have a working fix that does the following. Just need to write some tests for it to go through.

But basically you can supply query strings via path or by init obj. Both will work at the same time.

It will uri encode the query strings and add to the signer using rfc3986 so that it works with characters like ' etc, that are not encoding with standard encodeURIComponent etc.

It will tranform the url + path to not include the query strings but move them to the axios clients params object which will handle encoding for the query strings when sending the request.

I will see tonight if I have the time to finish all the tests or not. I have tried it quite a lot today.
So anyone need tro try a quick fix just let me know.

[lzbikowski]

Hi there,
Thanks for the fix, any chance to get that merged ?
It's very disturbing miss...

[leezen]

Relatedly, it doesn't appear that the SDK is properly encoding path parameters either. For example, if a path parameter has a '%' or '@' in it, the signature will be incorrect and the request will fail.

[nuttmeister]

Sorry for the late reply, I have been away for a while. I will try to update the coverage this weekend so the PR can be merged. The fix should fix the %, @ as well.

Have you tried the PR manually @leezen ?

[leezen]

Are you referring to this PR? https://github.com/aws/aws-amplify/pull/378/files -- if so, I think it won't address the problem I'm mentioning because nothing is touching the path segments. Referring to https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html -- the path segments must be URI encoded. So I think you would need to also apply fixed_encodeURIComponent to each of the path parts before signing.

For example, if I am trying to access http://example.com/api/restaurants/eat@joes/menu then 'eat@joes' needs to be encoded to 'eat%40joes' prior to signing.

[causingchaos2]

I can confirm this works fine:

`API.post('trips', '/days', { body: { content: "this is some text', imageURL: 'image-s3-url' } } )`

//then on the other side using serverless-webpack, you can simply parse the variables out by doing:
const data = JSON.parse(event.body)
console.log(data.content)
console.log(data.image-s3-URL)

You can easily pull out stuff from the body.

However, this does not work:
return API.get('trips','/days', {'queryStringParameters': {'param1': "99b60260-363c-11e8-b7ca-250a890d0675"}})

This will ALWAYS send a null parameter for the JSON object, whether it be body, or queryStringParameter JSON object.

and event.queryStringParameter will == null on the API side of your code.

[causingchaos2]

I hope they add this to amplify soon! :) ... Appending the query parameters to the path is fine for now I guess, however, I still fail to see how to access more then one of these... or how to build the path string properly using "?param1={value}&param2={value2}

[nuttmeister]

@leezen ahhh, ok. yeah, it's just going to be uriencoded by axios default uri encoding. so will not work in that case.

i can add the fixed uri encoding to the path segment as well this weekend if that will make you happy :P

[leezen]

Sure! That will save me from having to make an additional PR :) Looking forward to seeing the change merged in!