While making a xhr request from my application browser sends OPTIONS request since i am using endpoints in my project i have all request that have api key with their requests therefore options request also contains api key.
For my api key i have set some http referers on cloud console
Therefore while making OPTIONS request it shows
Referrer Policy:no-referrer-when-downgrade
and no referer is attached to my requests headers for OPTIONS request
hence it shows 403 error to my requests
Related
Because I have a backend api with http url, if I need to call api from frontend I need to send api request through http. My frontend was deployed to AWS Amplify, it runs as https. When I send api request it was blocked. console said: Mixed Content: The page at https//XXXX was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint http://XXXXX This request has been blocked; the content must be served over HTTPS.
how can I use http request here?
I'm planning on setting up ALB (Amazon Load Balancer) for authentication. It'll sit in front of my client app and only forward authenticated requests with the access_token and user claim jwt's as headers, x-amzn-oidc-accesstoken + x-amzn-oidc-data respectively [0].
My client application will need to capture these forwarded headers and store them in localStorage for accessing other AWS resources in later requests (ex. S3).
If I'm the client app receiving the ALB request, how would I intercept these headers? Would they come in as a request or response?
[0] See step #10 in the diagram: https://www.exampleloadbalancer.com/auth_detail.html
These headers wouldn't be received by your client by default. The client makes a request to the ALB and, after the user is authenticated, the ALB would pass the headers to your backend.
If the client needs these headers, your backend could add them to the response headers and your client could then retrieve them there.
That being said, keep in mind that if you do return these headers to the client, that anyone using some simple browser debug tools can see the headers and then craft their own requests using them. It may be better add the functionality that you need to the backend so that no credentials are potentially exposed to users.
I have a AWS Cloudfront hosted webpage which takes static pages from S3 and makes calls to custom origin (ALB) for dynamic data. There is OIDC authentication enabled on ALB, so calls to custom origin (my API) passes via rules set at ALB.
In a particular case when my request to custom origin is unauthenticated I am redirected to IdP for login and after successful login I get the cookie in the response header, as this request was sent to IdP from ALB - the issued cookie has domain as ALB DNS. In order for my webpage to use this cookie I have to redirect the call to Cloudfront URL. Now the cookie was issued to ALB which has a different DNS and my Cloudfront URL has a different DNS therefore I am unable to use the cookie.
I tried to catch the cookie value but because it is issued for a different domain i am unable to catch hold, also as a part of design I feel that is wrong. Has some one faced similar type of issue.
AWS ALB OIDC sets session cookie for the same request host domain for which you configure the authentication action in the listener rules.
Also, they set a http only secure cookie, meaning you cannot access it via client side Javascript at all.
Considering this along with your setup, it seems you actually need a (tiny) backend for your web page, so that you can access the response cookie when you make the API call to the mentioned custom origin internally from this backend.
I have seen posts about this but no questions or answers that match my problem closely enough to provide a valid answer.
I can not send requests to the API through my browser.
The problem, as far as I understand is that when you send a request to the API-gateway; the browser will first send a preflight options request. this preflight request will not add any custom headers ie: x-apigw-api-id header. This then causes a 403 to be returned without even hitting the options request.
My understanding is that the client has no control over the preflight request, it is handled by the browser.
The get request works through postman and so does the options request but only if I add the x-apigw-api-id header for each request.
headers returned through postman with x-apigw-api-id added to request
{"Access-Control-Allow-Origin":"*","Access-Control-Allow-Methods":"GET,OPTIONS","Access-Control-Allow-Headers":"Content-Type,X-Api-Key,","Content-Type":"application/json"}
I remove the header I get a 403 forbidden.
Is there a workaround for this problem? perhaps not needing the x-apigw-api-id when sending an options request?
Some of the questions I looked up prior to posting:
API Gateway CORS: no 'Access-Control-Allow-Origin' header
Can't use custom Request Headers on AWS API Gateway with CORS
request api gateway cors error
AWS API Gateway No 'Access-Control-Allow-Origin' header is present
AWS API Gateway endpoint gives CORS error when POST from static site on S3
This issue can be solved by associating a VPC endpoint to your private API. This will generate a Route53 alias to your private API. From the documentation,
When you associate a VPC endpoint with your private API, API Gateway generates a new Route53 ALIAS DNS record which you can use to invoke your private APIs just as you do your edge-optimized or regional APIs without overriding a Host header or passing an x-apigw-api-id header.
https://docs.aws.amazon.com/apigateway/latest/developerguide/associate-private-api-with-vpc-endpoint.html
Based in the solution exposed by Ulrar. A private API gateway expose an option for make request without use any additional header. This URL is formed by:
https://< api-id >-< vpce-id >.execute-api.< region >.amazonaws.com
This solution is useful for CORS issues in direct browser integrations.
I have my website like this "https://hr.mywebsite.com", I am able to go to my website when i type the whole url(https://hr.mywebsite.com).
But I want to go to my website without typing "https://".
That is if i type "hr.mywebsite.com" it should open my website. My website is hosted on AWS CloudFront.
You need to set an HTTP to HTTPS redirect on your CloudFront distribution. CloudFront has a setting for this.
To configure CloudFront to require HTTPS between viewers and CloudFront
Sign in to the AWS Management Console and open the CloudFront console at https://console.aws.amazon.com/cloudfront/.
In the top pane of the CloudFront console, choose the ID for the distribution that you want to update.
On the Behaviors tab, choose the cache behavior that you want to update, and then choose Edit.
Specify one of the following values for Viewer Protocol Policy:
Redirect HTTP to HTTPS
Viewers can use both protocols. HTTP GET and HEAD requests are automatically redirected to HTTPS requests. CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL. The viewer then resubmits the request to CloudFront using the HTTPS URL.
Important
CloudFront doesn't redirect DELETE, OPTIONS, PATCH, POST, or PUT requests from HTTP to HTTPS. If you configure a cache behavior to redirect to HTTPS, CloudFront responds to HTTP DELETE, OPTIONS, PATCH, POST, or PUT requests for that cache behavior with HTTP status code 403 (Forbidden).
When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests. For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer. For the HTTPS request, the charge is for the request, and for the headers and the object that are returned by your origin.
From http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html