My API is a request that can potentially have spaces in the pathParameters.
/data/{id}/hello/{Some message with a space}.
A sample request would be /data/23/hello/Say%20Hi
My angular code from the frontend encodes the request URL that is sent out to the AWS API Gateway but I get the following error.
`The Canonical String for this request should have been
'GET
/data/23/hello/Sayr%2520Hi`
My API gateway has a velocity template the decodes the parameters using $util.urlDecode()
I'm facing the same problem.
I've been stuck for a day.
If you are using HttpApi it cannot be solved.
Nevertheless, if you use RestApi I managed to make this work.
Specifically, you should use the URL Path Parameters.
You should:
Add a resource containing the /{variable}
Add a Url Path Parameter in the Integration Request Configuration with name variable and mapped from method.request.path.variable
Notice that the solution may depend on the integration type that you are using.
In the screenshot below you can see how I'm redirecting all the received traffic to a NetworkLoadBalancer.
The resource has the variable /{proxy+}, the endpoint URL has the {proxy}, and, in the URL Path Parameters, I've configured the mapping method.request.path.proxy.
I have a scheduled job in GCP that POSTs to the endpoint of a REST service. The payload expected by the url is
{"foo": ["bar"]}
I specified "{\"foo\": \[\"bar\"\]}" in the Body field in the web console :
AND specified application/json in the Content-Type header.
But I get 400 error from the endpoint (Bad request). The endpoint is working perfectly fine when requested from the swagger, so I think the problem comes from how I specify the payload in the cron job.
How should I write the payload in Cloud Scheduler web interface ?
Simply use you raw JSON {"foo": ["bar"]}. The escape characters are for gcloud CLI.
I am trying to perform GetBucketCors operation using REST API and new AWS4 authorization. It works perfectly when I use old auth method but I cannot find out how to set canonical request right in AWS4.
I am trying to add 'cors' as first query parameter and include it into canonical request but in most of times I get error: "The request signature we calculated does not match the signature you provided. Check your key and signing method."
Can you suggest what should right query string should be? This is noh my canonical request looks like:
GET
/
cors&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJSZ2LLOUSEHIJVQQ%2F20210316%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210316T192947Z&X-Amz-Expires=10&X-Amz-SignedHeaders=host
host:<BUCKET_NAME>.s3.amazonaws.com
host
UNSIGNED-PAYLOAD
OK, I have finally found it out (hint: look at amazon response more ;)
"cors" should be additional query param with "="
GET
/<BUCKET_NAME>/
X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJSZ2LLOUSEHIJVQQ%2F20210317%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210317T210203Z&X-Amz-Expires=10&X-Amz-SignedHeaders=host&cors=
host:s3.amazonaws.com
host
UNSIGNED-PAYLOAD
I'm trying to gracefully handle the 403 when visiting an S3 resource via an expired URL. Currently it returns an amz xml error page. I have uploaded a 403.html resource and thought I could redirect to that.
The bucket resources are assets saved/fetched by my app. Still, reading the docs I set bucket properties to handle the bucket as a static webpage page and uploaded a 403.html to bucket root. All public permissions are blocked, except public GET access to the resource 403.html. In bucket properties, website settings I indicated the 403.html as error page. Visiting http://<bucket>.s3-website-us-east-1.amazonaws.com/some-asset.html redirects correctly to http://<bucket>.s3-website-us-east-1.amazonaws.com/403.html
However, when I use aws-sdk js/node and call method getSignedUrl('getObject', params) to generate the signed url, it returns a different host url: https://<bucket>.s3.amazonaws.com/ Visiting expired resources from this method do not get redirected to 403.html. I'm guessing that since the host address is different this is the reason it is not automatically redirecting.
I have also set up static website routing rules for condition
<Condition>
<HttpErrorCodeReturnedEquals>403</HttpErrorCodeReturnedEquals>
</Condition>
<Redirect>
<ReplaceKeyWith>403.html</ReplaceKeyWith>
</Redirect>
Still that's not redirecting the signed urls. So I'm at a loss of how to gracefully handle these expired urls. Any help would be greatly appreciated.
S3 buckets have 2 public-facing interfaces, REST and website. That is the difference between the two hostnames, and the difference in behavior you are seeing.
They have two different feature sets.
feature REST Endpoint Website Endpoint
---------------- ------------------- -------------------
Access control yes no, public content only
Error messages XML HTML
Redirection no yes, bucket, rule, and object-level
Request types all supported GET and HEAD only
Root of bucket lists keys returns index document
SSL yes no
Source: http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html
So, as you can see from the table, the REST endpoint supports signed URLs, but not friendly errors, while the website endpoint supports friendly errors, but not signed URLs. The two can't be mixed and matched, so what you're trying to do isn't natively supported by S3.
I have worked around this limitation by passing all requests for the bucket through HAProxy on an EC2 instance and on to the REST endpoint for the bucket.
When a 403 error message is returned, the proxy modifies the response body XML using the new embedded Lua interpreter, adding this before the <Error> tag.
<?xml-stylesheet type="text/xsl" href="/error.xsl"?>\n
The file /error.xsl is publicly readable, and uses browser-side XSLT to render a pretty error response.
The proxy also injects a couple of additional tags into the xml, <ProxyTime> and <ProxyHTTPCode> for use in the output. The resulting XML looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/error.xsl"?>
<Error><ProxyTime>2015-10-13T17:36:01Z</ProxyTime><ProxyHTTPCode>403</ProxyHTTPCode><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>9D3E05D20C1BD6AC</RequestId><HostId>WvdkvIRIDMjfa/1Oi3DGVOTR0hABCDEFGHIJKLMNOPQRSTUVWXYZ+B8thZahg7W/I/ExAmPlEAQ=</HostId></Error>
Then I vary the output shown to the user with XSL tests to determine what error condition S3 has thrown:
<xsl:if test="//Code = 'AccessDenied'">
<p>It seems we may have provided you with a link to a resource to which you do not have access, or a resource which does not exist, or that our internal security mechanisms were unable to reach consensus on your authorization to view it.</p>
</xsl:if>
And the final result looks like this:
The above is a general "Access Denied" because no credentials were supplied. Here's an example of an expired signature.
I don't include the HostId in the output, since it's ugly and noisy, and, if I ever need it, the proxy captured and logged it for me, and I can cross-reference to the request-id.
As a bonus, of course, running the requests through my proxy means I can use my own domain name and my own SSL certificate when serving up bucket content, and I have real-time access logs with no delay. When the proxy is in the same region as the bucket, there is no additional charge for the extra step of data transfer, and I've been very happy with this setup.
So I'm having trouble making an API request to amazon and returning XML that displays product information, particularly price. I'm using the signed request helper to generate my requests, and have been following the examples in the AWS documentation.
here is my request URL and params:
http://webservices.amazon.com/onca/xml?
Service=AWSECommerceService
&Operation=ItemLookup
&ResponseGroup=OfferFull
&Condition=All
&IdType=ASIN
&ItemId=B001L8NG0Q
the helper also generates my signature, access keys, etc. However this is what is returned what I submit this request:
<ErrorResponse xmlns="http://ecs.amazonaws.com/doc/2005-10-05/">
<Error>
<Code>InvalidAction</Code>
<Message>
The action ItemLookup is not valid for this endpoint.
</Message>
</Error>
<RequestId>a006f1ec-11b3-4afd-a5a3-cb8cfd7e4186</RequestId>
</ErrorResponse>
Any ideas on what my problem is here? I seem to be able to get this to work just fine for keyword queries, but i'm having trouble with this item lookup.