I am new to meteor+ionic2, I am trying to make an app where I need to make an http call and pass some parameters in headers, It is giving the error missing token ‘language’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel,
I tried providing proxies in ionic.config.json and even whitelisting url in mobile-config.js, but none of them helps, please help.
Note: It works when I use plugin to allow CORS in Chrome
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?
I have a django backend and a Vue 3 frontend.
For handling some request, my backend needs an 'Id-Client' header in the headers of the request.
Developing my BE everything worked like a charm, but now that I'm writing the FE I'm encountering some issues.
As I said before, I need to append an header to my headers in every request.
So the first step was the following:
// Note that the idClient is dynamic and can change.
this.$axios.setHeader('Id-Client', idClient)
const data = await this.$axios.$get(url)
But I can't get it to work, if I try to send that request, my GET request becomes (I don't know why) a OPTIONS request and I get the error "cross origin resource sharing error: HeaderDisallowedByPreflightResponse"
Instead if I remove the set header
// this.$axios.setHeader('Id-Client', idClient)
const data = await this.$axios.$get(url)
The server just respond me correctly giving me the error that the request is missing the 'Id-Client' in the header.
I also have a few request that don't need the 'Id-client' header and those request work, so I don't think is a CORS problem.
Well but is looks like CORS issue. CORS policies are not triggered by simple requests. By adding custom header, your requests are no longer simple and trigger CORS policies (sending OPTIONS before GET)
Your only option is to configure your backend server to reply to OPTIONS requests with the correct headers - Access-Control-Allow-Origin and Access-Control-Allow-Headers (server telling the browser "yes, im ok to accept particular custom header")
IF (and only if) you are planning to serve your Vue SPA from the same API server in production (same origin), you can avoid similar CORS issues during development by using Webpack Dev server Proxy - your SPA will send API requests to Webpack Dev Server (used for developing SPA) and Proxy will route it to your Django dev server. That way all request from your SPA are to the same origin and you don't need to care about CORS at all...
I'm almost complete with a new web app, however, I'm getting a 403 error from AWS's API Gateway due to a CORs issue.
I'm creating a Vue app and using Vue's axios library. CORs is enabled and the request works with API Key Required option turned off in AWS's API Gateway by sending the following:
axios
.get('My-URL-Endpoint',{headers: {})
.then(response => (this.passports = response.data ));
When I turn on API Key Required functionality inside AWS's API Gateway. It works when I use Postman along with including x-api-key: My-API-Key. However, using Vue's axios it does not work and returns error 403:
axios
.get('My-URL-Endpoint', {headers: {
'x-api-key': 'My-API-Key'
}})
.then(response => (this.passports = response.data ));
My first instinct is that the problem is related to how Axios is sending the request through the browser. From what I can gather it looks like the pre-flight check is failing because I am receiving the following error within the browser:
Access to XMLHttpRequest at 'My-URL' from origin 'http://localhost:8080' 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.
Sure enough it looks like there is no access-control-allow-origin key in the response. So I added access-control-allow-origin to the response of the 403 message and got a new error "It does not have HTTP ok status"
I've been trying nearly everything to get this to work! I came across stackoverflow answer where it seems like the person was suggesting that API Key Required Key functionality can't work with CORs. This kind of seemed like that cannot be true. It would be a pretty crippling restriction.
So my question is how to get the browser's pre-flight check to work along with CORs and API Key capability inside AWS's API Gateway?
Thank you!
If you have enabled cors on your api gateway, the next place to look is the application code such as lambda. Make sure the Lambda is returning the correct cross origin headers in both successful and failure scenarios.
First of all you can check if the request is reaching the lambda from the cloud watch logs. Another way to check this is to temporarily point the Api gateway target to the Mock end point.
If the mock endpoint works, then the problem is the application code. otherwise the problem is in your api gateway end point.
Also note that any headers you use should be white listed in the Access-Control-Allow-headers section when you enable to cors for your method/resource.
My API has an OPTIONS method that is implemented through a Mock integration that is set to return the required CORS headers.
The problem is that it returns 500 Internal Server Error when there is no Content-Type set on the OPTIONS request. It is returning proper CORS headers with a 200 Success when Content-Type is set to application/json.
How do I fix this as the OPTIONS request is sent by the browser and I don't think I'm allowed to set Content-Type header on it?
You can set Content-Type headers in API Gateway. Refer this link I hope it should helps
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
My app is an Ember.js front end with a Go API on the server. I created the Ember app using the FixtureAdapter. Now that I have the Go API back end I converted it to RESTAdapter.
When I hit my API directly with the browser, I seem to get the appropriate CORS headers back:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin,x-requested-with
Access-Control-Allow-Methods:PUT,PATCH,GET,POST
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:Content-Length
However, when my Ember.js app hits the API, I get XMLHttpRequest cannot load https://192.168.59.103:8001/notifications. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.59.103:9000' is therefore not allowed access..
I don't know how else to see what's going on between Ember and the API. I've read this CORS tutorial and everything seems to be okay on the server end.
I included the bit about x-requested-with because of another Stack Overflow question suggesting that jQuery requests need something different than plain old JavaScript requests.
Your endpoints also need to respond with CORS headers to OPTIONS requests- those will execute before the actual request to make sure that the request is allowed first.
Do you happen to be using Nginx as your reverse proxy for your API? If so, we experienced this same issue. In our case, the problem was that Nginx returns the correct CORS headers just fine for HTTP 200 OK responses, but for any error response, it will fail to add the COR headers and therefore the actual server response gets obscured by the browser complaining that it doesn't have the appropriate CORS headers to render a response.
See https://serverfault.com/a/431580/199943.
Even if you're not using Nginx, try calling your API directly (e.g. using Postman to avoid the CORS restrictions to see what it's returning. If your API is returning anything other than an HTTP 200 OK, that may be why the CORS headers aren't getting added.