I know this is a known problem but it seems new version v5.11.0 brings another problem related to CORS.
According to this documentation, you just need to configure CORS behavior to make call from application out of I.S. domain.
I did this configuration, but it doesn't work. When I call endpoint /oauth2/oidcdiscovery/.well-known/openid-configuration, I get following error:
Access to XMLHttpRequest at 'https://xxxx:9443/oauth2/oidcdiscovery/.well-known/openid-configuration' from origin 'http://localhost:4200' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Does anybody facing same problem?
Thanks,
You need to follow this cors configuration given in this doc. From 5.11 onwards, IS has changed the cors configuration model. Check the new changes done for 5.11 here. So the configuration mentioned in this documentation
is no longer valid
Related
I am setting up a flask-dance + flask-login project and am having issues with CORS. Specifically, I follow the standard flask-dance setup for Google OAuth:
google_blueprint = make_google_blueprint(
client_id=constants.GOOGLE_CLIENT_ID,
client_secret=constants.GOOGLE_CLIENT_SECRET,
scope=["profile", "email"]
)
app.register_blueprint(google_blueprint, url_prefix="/b/google_login")
On the frontend, I make a GET request to {backend}::/b/google_login/google, but get the following error:
Access to XMLHttpRequest at 'https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=xxx&redirect_uri=http%3A%2F%2Flocalhost%3A5001%2Fb%2Fgoogle_login%2Fgoogle%2Fauthorized&scope=profile+email&state=xxx' (redirected from 'http://localhost:5001/b/google_login/google')
from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I have added the redirect URI (i.e. /b/google_login/google/authorized to the redirect-URI whitelist). I am confused why this error is happening - as I am proxying the OAuth redirect through my server.
When I attempt the flow through window.href = http://localhost:5001/b/google_login/google - the flow works without issue.
Anyone have any idea why this is happening?
When I attempt to make a call to https://login.tapkey.com/connect/token using a code returned in the authentication stage from the client I get a CORS error, I however I'm able to make that call from the BackenEnd.
CORS applies only to browser clients. That's the nature of CORS restrictions and what they should prevent.
Make sure that you setup the correct hostname in the client configuration in the developer section.
I was trying to use my api and I have a function on ember app to login but when the login action is trigerred I receive a message below. What is the reason I am receiving this error?
login:1 Access to fetch at 'https://app-dev.some-url.com.au/api/login' from origin
'http://localhost:4099' has been blocked by CORS policy: Response to preflight request doesn't
pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested
resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch
the resource with CORS disabled.
Your API server isn’t configured to accept requests that come from a web application on another origin. Some options:
Configure your API to serve the Access-Control-Allow-Origin header
on the OPTIONS request that the browser makes to test this. It
could be Access-Control-Allow-Origin: * if you’re lazy or can’t
know in advance what origins people will be coming from. It’s hard
to be more specific about this without knowing details of your API.
Use Ember CLI’s API
proxying
feature to bypass the need for CORS. This is for development mode
only, though. You’d need a similar solution in production where
Ember CLI’s development server isn’t present.
I've created an API with C++ and the following library: https://github.com/yhirose/cpp-httplib
In the API I've added a header to responses for CORS:
svr.Post("/suggest", [&dr](const Request &req, Response &res){
res.set_header("Access-Control-Allow-Origin","(origin here)");
(origin here) is the origin of the server making the request.
On the browser side I've also enabled an extension to bypass CORS. But when trying to make an AJAX request to the API, I still get this error in my browser console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://192.168.1.10:10120/suggest. (Reason: CORS request did not succeed).
The AJAX request is done through a script written in the Tampermonkey extension to work on a specific website.
Do I need to modify headers on the server hosting the website? Have I done something wrong on the C++ side?
Also it might be important to mention that the code worked before. All I did was come back to it another day with a different local IP address (which i reprogrammed into the c++ API)
I tried it again to answer #sideshowbarker and it gave me a new error about self signed certificates. After adding the exception it worked.
I have a deployed web app, it's built with a React & Redux frontend hosted on S3, and a several backend micro-services hosted on AWS Lambda and exposed over API Gateway that were deployed with Serverless. The site is also distributed via a CloudFront CDN.
The micro-services interact with several external services but the primary one I am concerned with is the get-products service which queries the Stripe product database and returns the products to my React app from there.
The site has been working fine until yesterday when I deployed some new (basically cosmetic) changes to front end, and added some more SKUs to the Stripe database. Since adding these changes I have started to experience CORS errors where previously there were none.
Initially I got the following error:
Access to XMLHttpRequest at 'https://XXXXXXXXXX.execute-api.eu-west-1.amazonaws.com/dev/products' from origin 'https://www.superfunwebsite.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
This was despite my Lambda response including the following headers:
'Access-Control-Allow-Origin': '*',
At this point I updated my Lambdas response headers to the following:
'Access-Control-Allow-Origin': 'https://www.superfunwebsite.com/',
'Access-Control-Allow-Credentials': true
The error has largely persisted, except for on one random page load where instead I got an error stating that the Origin https://www.superfunwebsite.com and 'Access-Control-Allow-Origin' https://www.superfunwebsite.com/ didn't match.
I've since changed the Lambda response headers to this:
'Access-Control-Allow-Origin': 'https://www.superfunwebsite.com',
'Access-Control-Allow-Credentials': true
Which seems as though it may have solved that anomalous second error.
However, error one persists even when I am testing using a HTTP client like Insomnia. I get the following in the response.
// status code
403
// response
{
"message": "Forbidden"
}
// headers
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
Date: Tue, 18 Sep 2018 13:22:41 GMT
x-amzn-RequestId: eb691541-bb45-11e8-82ff-6d1b542dffb9
x-amzn-ErrorType: ForbiddenException
x-amz-apigw-id: NaxVLGJgjoEF5Fg=
X-Cache: Error from cloudfront
Via: 1.1 08037e15a3c6f503f39825efeb7f0210.cloudfront.net (CloudFront)
X-Amz-Cf-Id: cbNtb4xKWc48VPFon-Cl9y27KmXRVLIN5SWuYwNWlWsTXeaAXx3z-Q==
Based on the above Insomnia output it seems that my issue is somehow related to CloudFront although I don't understand exactly how. This other S/O post seems to indicate that there should be options for me in the CloudFront behaviours section that would allow me to whitelist headers for the response, however these options are not visible to me in the console, I've seen suggestions this is because the origin is on S3.
My question is simply if anyone knows how I can fix this issue or if there is something else I've not considered that I should be looking at?
Here you have to Whitelist the respective CORS headers in the behaviour section of the cloudfront distribution.
Open your distribution from the Amazon CloudFront console
Choose the Behaviors view.
Choose Create Behavior, or choose an existing behavior and then choose Edit.
For option Cache Based on Selected Request Headers, choose Whitelist.
Under Whitelist Headers, choose headers (Access-Control-Request-Headers and Access-Control-request-methods, Origin) from the menu on the left, and then choose Add.
Choose Yes, Edit.
The above settings should work for you (as its mainly for GET and HEAD) but if it doesn't, enable OPTIONS method as well using below article.
Please check the below article from aws:
no-access-control-allow-origin-error
Custom CORS Cloudfront
enhanced-cloudfront-customization
This issue has now been solved. In the end it was not in fact a CORS issue but a staging one. My query was failing because I was querying an endpoint stage that did not exist.
It appears that in the set up I had using CloudFront and API Gateway, when querying an endpoint that didn't exist I was returned a 403 response without CORS headers.
The browser/CloudFront (not sure which) then identified the absence of CORS headers and threw an error in response to that.
In my case simply changing my endpoint from the dev stage (which did not exist on the associated AWS account associated with the live stage):
https://XXXXXXXXXX.execute-api.eu-west-1.amazonaws.com/dev/products
To the live stage:
https://XXXXXXXXXX.execute-api.eu-west-1.amazonaws.com/live/products
Resolved the issue immediately.