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.
Related
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 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.
Okay, I've been all over these interwebs looking for some insight to my issue; I've probably been through over 80 stack overflow threads RE api gateway and such, but none of them seem to help or speak close enough to my issue.
I'm new to API Gateway and cors, but lets see if i can articulate the issue that i am seeing:
Setting up a API gateway proxy to Kinesis firehose hydrating a redshift database. The proxy, firehose, and redshift gateway are up and working when called in isolation, but when called from one of our customer sites, we get an error as follows:
XMLHttpRequest cannot load [api_call_here]. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 403.
Okay, so that strongly implies that CORS is needed, right? in the console on the resource, enable cors, deploy, new error:
XMLHttpRequest cannot load [api_call_here]. Request header field $cookies is not allowed by Access-Control-Allow-Headers in preflight response.
Ooooooooookay, from the new OPTIONS method added by the enable CORS feature, in integration response, allowed headers, under access control allowed headers add '$Cookies', deploy.
Now i get a new error, very similar to the first error:
XMLHttpRequest cannot load [api_call_here]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 415.
Notice the first error had HTTP status code 403, and this third one has status code 415. This is where I'm having issues. If I go into the GET method acting as the proxy method, body mapping templates, I have "When there are no templates defined (recommended)" selected.
Now, I read that when API gateway fails to find a matching template it rejects with a 415 error, so I changed aforementioned option to "When no template matches the request Content-Type header". That made the error disappear, but the data is still not being persisted to redshift when called from the origin. Again, when I call the api directly from postman, insomnia or just a plain old address bar, the records are added nicely.
Opening up chrome and looking at the header i see that the cookie is coming across as text/html.
Regarding the template mapping up there, i have only defined a map for application/json; could that be part of the problem?
Also, the response header as viewed from chrome's console is as follows:
content-length:37
content-type:application/json
date:Wed, 19 Apr 2017 23:43:35 GMT
status:415
via:1.1 [blahblabbleblah].cloudfront.net (CloudFront)
x-amz-cf-id:[blahblabbleblah]
x-amzn-requestid:[blahblabbleblah]
x-cache:Error from cloudfront
I'm relatively new to this so i dont see how cloudfront fits in with this, especially give that it is complaining about media type while the console is complaining about no access-control-allow-origin header.
At any rate, any help as to how to resolve the third error would be most appreciated.
What is the content-type in your requests from the browser? If content-type header isn't specified in the request, then API Gateway assumes "application/json" by default.
Opening up chrome and looking at the header i see that the cookie is coming across as text/html.
I am not sure if you meant that "Content-type" header's value in the request is set to "text/html". If yes, that's the problem. You will either need a matching template, or you will need to pass through by default by choosing "When no template matches the request Content-Type header".
I have some issue with AWS API GW with SQS integration. Problem was that incorrect content type in mapping template, I wrote application/json but correct is application/x-www-form-urlencoded
The request body will never be passed through to the integration.
Requests with a Content-Type header that don't match any templates
will be rejected with a HTTP 415 response.
When I was trying to log, I got a Cross-Origin Error. Below is the complete error message.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://10.138.31.41:8243/insurance/1.0.0/i_customers/q?{%22username%22:%22q%22}. This can be fixed by moving the resource to the same domain or enabling CORS.
When your request is not sent from the same origin, browsers will send an options-request to the target server to make sure, whether the target server allows requests from the foreign origin with given http-method and headers for the requested endpoint.
It seems like the target server blocks your requests, so you should make sure, that the cors-response from your target server is adjusted (meaning it includes an "Access-Control-Allow-Origin"-Header listing the url your request comes from) or not rejected (maybe your request gets rejected, because you are requesting via https but ip-based, to the certificate is not accepted). If this is not possible, you could "bypass" the Same-Origin-Policy-Check from your browser with a jsonp-request (only http-get) or by sending the request over a reverse-proxy.
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.