i've made an api gateway with a lambda function, the api works fine over rest clients, and over browser.
when i created a api key and made it obligatory for the post request, it works fine over rest client but no more over the browser, it sais
No 'Access-Control-Allow-Origin' header
this by knowing that all CORS are activated, and "X-Api-Key" is in the cors headers
Enable CORS in AWS API Gateway
from API Gateway choose the API resource or method and click on the Actions button, it will display a list of options. Select Enable CORS options from the options and deploy the API by choosing Deploy API option. It will enable CORS to the selected Resource or Method.
note: I don't have enough reputation to embed the image in answer that's why the image link is provided.
Related
My intention is to create an HTTP API on Amazon API Gateway that writes a file to S3 using the PutObject action via the S3 API (without calling Lambda in between). This is the PutObject request syntax: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html#API_PutObject_RequestSyntax
I'm not sure if this is technically possible and I'm getting a 403 Forbidden: ForbiddenException response in Postman.
So far I have:
Created the S3 bucket (with CORS configured)
Created the HTTP API in API Gateway (with CORS configured), with a 'putObject' POST action
Configured an integration on the HTTP API to https://[s3-bucket-name].s3.us-east-1.amazonaws.com
Create a Postman request to the HTTP API 'invoke URL', with 'Host' and 'x-apigw-api-id' set on the headers
The ForbiddenException obviously indicates a permission issue, either on the HTTP API or the S3 API behind it. I did configure a Cloudwatch Log Group on the HTTP API, which is showing no entries, so it seems that it's an HTTP API access issue.
I also suspect that I need to add Parameter Mappings to the HTTP API to pass in all of the necessary headers to the S3 putObject action.
My questions are:
Is this type of HTTP API integration direct to S3 possible?
What is the likely cause of the 403 Forbidden response from the service?
Would I use 'Append' Parameter Mappings in the HTTP API integration configuration to add the standard S3 API parameters (and avoid exposing them to the client)?
I managed to solve this myself. Answers to my own questions:
Is this type of HTTP API integration direct to S3 possible?
Yes. On my HTTP API I used an HTTP PUT integration that points to the S3 service endpoint (including the bucket name in the endpoint is incorrect).
What is the likely cause of the 403 Forbidden response from the service?
I didn't get the request working from Postman, however, when I made the request from the browser it worked. I had to create a Blob in Javascript before sending it as a request via navigator.beacon() to the HTTP API endpoint URL.
Would I use 'Append' Parameter Mappings in the HTTP API integration configuration to add the standard S3 API parameters (and avoid exposing them to the client)?
I did have to use Parameter Mappings to get the S3 PutObject request to work from API Gateway. My configuration is shown below.
Screenshot of Parameter Mapping configuration in my HTTP API
Edit: I have discovered a problem here with this approach: the HTTP API doesn't allow certain security-related headers to be added on the Parameter Mappings. I was trying to set header.x-amz-acl: 'bucket-owner-full-control' but I got the error message below:
Invalid mapping expression specified: Validation Result: warnings : [], errors : [Operations on header x-amz-acl are restricted]
It seems that modifying any security-related S3 API header isn't possible in the HTTP API. This is a major problem for calling the S3 API directly as it means that in order to function, the S3 bucket needs to be public.
I currently have the following architecture
APP -> API -> KeyCloak
I want the APP to be able to send requests to my API which will then internally proxy certain requests to KeyCloak. For example, I'd like to make a request to the /userinfo endpoint in KeyCloak through my API. If I can figure this out I can then perform more complex features.
APP -> http://api:port/api/userinfo
API -> http://keycloak:port/auth/realms/quartech/protocol/openid-connect/userinfo
I have a valid JWT Bearer token. As I can directly make the request to KeyCloak successfully, however if I attempt to make the request via my API it returns 401. Even though it is using the same JWT Bearer token.
I believe it has something to do with configuring the KeyCloak client to allow requests to come from the API. But so far I haven't been able to figure it out.
I've discovered it required a DNS entry to local development within a Docker container.
I've edited the hosts file and added a 127.0.0.1 keycloak and then al
I am using Anypoint Studio 6.1 and Mule 3.8.1 and have a mule RESTful application that I want to stop CORS requests from being accepted by the application.
The application has been setup to do this but what is the best way to prove this is working?
From what I have read so far, the examples build their own application and I would just like to do something like send a request configured as a CORS request in Postman. How can I do this?
Thanks
I want to stop CORS requests from being accepted by the application.
I would just like to do something like send a request configured as a CORS request in Postman
You mean you want to block cross-origin requests just from Web applications running in browsers?
Given that browsers are the only tools that enforce CORS restrictions, and they only do it for requests from code running in actual Web apps—not for requests from extension such as Postman that aren’t bound by the same-origin policy that Web apps are—then you’re not going to be able to use CORS to block requests from Postman or from code not running from a Web app in a browser.
The application has been setup to do this but what is the best way to prove this is working?
Confirm the service isn’t sending an Access-Control-Allow-Origin response header—which it never would be unless either it were explicitly configured to do that or it’s built using some server-side programming environment/framework that adds Access-Control-Allow-Origin by default.
But since browsers are the only tools that are ever actually going to block cross-origin requests due to lack of Access-Control-Allow-Origin, you really can only test the blocking in a Web app.
Otherwise you can at least test outside the browser to see what response headers are returned by the server the requests are sent to. The main thing to do in that case is to be sure the request send an Origin header (some servers only send Access-Control-Allow-Origin if a request includes an Origin header—because browsers are the only tools that automatically send Origin.
So, using curl for example, you’d want to do this:
curl -H "Origin: https://example.com" https://service.to.test/
Have installed the API Manager 1.10.0 on a single machine and got everything running. Created and published API containing Openstack's Keystone URL. However when i try to consume API via API console in API store i get the MANAGEMENT CONSOLE as i response.
Have looked at the curl sent and the IP is not right.
Curl request from API Console
Keystone API URLs
Why am i not able to use the API? Why is the Production endpoint in the API overview not used? (it works perfectly fine with a REST Client or even with the same Curl request once i change to IP)
When we construct API endpoint URLs we will use following properties defined in API Manager configuration file(api-manager.xml). If you haven't changed anything there then default ports(8280/8243) will appear there. If you can please try this with private browsing window with https session.
And if you replace curl with IP and correct port 8280, 8243 then did it worked as expected?
<GatewayEndpoint>http://${carbon.local.ip}:${http.nio.port},https://${carbon.local.ip}:${https.nio.port}</GatewayEndpoint>
Thanks
sanjeewa.
I have a client-side angular-js application. And I have a server-side nodejs API. The client-side and the server-side application are located on different domains. The client-side use API for getting or posting some data. Also the client-side needs to get images from the server-side and show them in a browser.
I use passport nodejs module for the authentication. I don't know which authentication strategy is better for me. I think that there are two types of authentication strategies: token-based and cookie-based. And I think that both types useless in my case:
If I use token-based strategies, then I should send Authentication header with a token in each request to the API. I can send headers in AJAX requests, but if I want to show an image that is located on the server-side I have a problem. Because a browser will not send headers in <img> tag.
If I use cookies, then I don't have the problem with images. But I have problems with AJAX requests. Because the session cookie is stored on the server-side application's domain. And if I send AJAX requests from the client-side domain, then I should send cookies with each request. I use XmlHttpRequest for AJAX and I should use withCredentials option for sending cookies. But in crossdomain requests browsers will send a preflight (OPTION) request before each AJAX request. And browsers will not send cookies with OPTION request. This is a problem for me because the server-side API could not make a correct response on an OPTION request if it will be not authorized.
What is the adopted solution?
It is important to understand the difference between web applications and web services. A web application serves markup, JavaScript, CSS and image files and often uses cookie based authentication (but can use any other implicit authentication mechanism). Any request the browser makes is automatically authenticated.
Web services on the other hand often use bearer token authentication. When a client in a browser, fat client or on a mobile device communicates with the API, it sends along a token in the Authorization header of the HTTP request. The header has to be explicitly attached to the request in the JavaScript or native code executing the HTTP request.
In Single Page Applications (SPA), the web application is missing and the markup, JavaScript, CSS and images are served from the browser without authentication. Only the requests to the web services are authenticated, typically using a JWT token.
In your case, if you want only authorized users to be able to download images, and other files, you should consider building a web application. Use a security protocol like or OpenID Connect to authenticate your users. Choose an authorization server that supports both OpenID Connect for your web application and OAuth2 for your web service.