I needed to use the StackOverflow API to retrieve some data from the site. Actually, when I tried the first time to use the API I got an exception due to CORS policy.
Access to fetch at 'https://stackoverflow.com/users/myID/reputation'
from origin 'http://localhost:3000' has been blocked by CORS policy:
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.
I understand that the reason why my request was blocked was that the header was not in the response. However, does not StackExchange API attach in the response header Access-Control-Allow-Origin? I'm doing something wrong in how I'm invoking the request?
does not StackExchange API attach in the response header Access-Control-Allow-Origin? I'm doing something wrong in how I'm invoking the request?
The Stack Exchange API permits client-side requests, but the page you're requesting is not the Stack Exchange API - it's just a plain Stack Exchange page, not the API endpoint designed for such things, so it doesn't have the required header.
If you want to use the API properly, go through the documentation here and choose the endpoint you need. For an example using my user ID, one might use the following code:
fetch('https://api.stackexchange.com/2.2/users/9515207/reputation?site=stackoverflow')
.then(res => res.json())
.then(console.log);
api.stackexchange.com has the proper headers: access-control-allow-origin: *, which allows for client-side scripts to request it.
since this request is for a trial project, can I implement a proxy using a free-tier of some platform? I see a lot of suggestions for Heroku but I'm not very familiar with that platform
For the more general case of a server that doesn't set the required headers, if you wanted to use one of their responses client-side, you would have to bounce the request off a relay server. You could either make your own app on Heroku (a good free option), or use something like https://cors-anywhere.herokuapp.com/
Related
I'm a n00b trying to learn React. I'm building a website that uses Etsy's APIs. Registered an app there and everything. They have a page that talks about CORS and proxying here: https://www.etsy.com/developers/documentation/getting_started/jsonp
So for example, I'm trying to do a fetch on a store's listings:
fetch('https://openapi.etsy.com/v2/shops/[shopId]/listings/active?api_key=[apiKey]')
But that violates the browser's CORS policy. No problem, says the documentation on Etsy. You can always use their proxy: beta-api.etsy.com. So I add that to my package.json file:
"proxy": "https://beta-api.etsy.com/"
And then I change my fetch line:
fetch('/v2/shops/[shopId]/listings/active?api_key=[apiKey]')
But CORS is still being violated in the browser.
Access to fetch at 'https://www.etsy.com/shop/beta-api/v2/shops/[shopId]/listings/active?api_key=[apiKey]' (redirected from 'http://localhost:3000/v2/shops/[shopId]/listings/active?api_key=[apiKey]') from origin 'http://localhost:3000' has been blocked by CORS policy: 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.
I don't want an opaque response, either, so doing "no-cors" really doesn't help. Does anyone have any recommendations on how I can at least get a local website up and running?
You are getting that error because your server has set Access-Control-Allow-Origin to restrict cross-domain traffic. You are sending your request from your localhost so that is considered cross-domain.
If you are able to change your server settings to set Access-Control-Allow-Origin: * then you can make those requests without a CORS error but I don't suggest doing this.
The best solution would probably be a proxy server. You can use cors-anywhere heroku app to easily do this.
Excerpt from Medium Article on this issue
The cors-anywhere server is a proxy that adds CORS headers to a
request. A proxy acts as an intermediary between a client and server.
In this case, the cors-anywhere proxy server operates in between the
frontend web app making the request, and the server that responds with
data.
Similar to the Allow-control-allow-origin plugin, it adds the
more open Access-Control-Allow-Origin: * header to the response.
Say your frontend is trying to make a GET request to:
https://joke-api-strict-cors.appspot.com/jokes/random
But this api does not have a Access-Control-Allow-Origin value
in place that permits the web application domain to access it.
So instead, send your GET request to:
https://cors-anywhere.herokuapp.com/https://joke-api-strict-cors.appspot.com/jokes/random
The proxy server receives the
https://joke-api-strict-cors.appspot.com/jokes/random
from the url above. Then it makes the request to get that server’s
response. And finally, the proxy applies the Access-Control-Allow-
Origin: * to that original response.
I succesfully installed "JWT Authentication for WP REST API" and followed (and reviewed multiple times) the instructions for setup correctly.
My React app does authenticate via the /jwt-auth/v1/token-endpoint.
I get a token back and store this in my localStorage.
All of my API-calls get added an authorization header as follows from this point on:
Authorization: Bearer mYCust0mToken
In the browser, this triggers preflight requests to the server (which is a remote one), that all fail. Basically logging in kills all of my API-requests.
I'm now getting 405's stating the following:
Access to fetch at
'https://mywebpage.com/wp-json/wp/v2/posts/'
from origin 'http://localhost:3000' 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.
I run WP inside a subdir, so I have two .htaccess files, one in the root, one in the wp/-directory. I've tried putting the suggested .htaccess-changes of the descriptions in both files, on several positions of the file, but still no luck.
I've also tried setting Allow-Origin headers to "*", just for the sake of testing. I did that in both the .htaccess-files, but also in my PHP.
Anyone out there that got "JWT Authentication for WP REST API" up and running and willing to tell how?
I have an AngularJs website and when I am trying to post data then when I am opening my website without using www then I am getting
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource
Otherwise, I am not getting any error.
I tried to search and found that I should implement CORS on my backend which is in NodeJs but can anyone please tell me how can I only implement CORS Headers such that for both www and without, it would work but for any other domain trying to access my API must result in preflight error.
I am trying to do this because I read here which-security-risks-do-cors-imply that allowing all domains can increase security overhead for my website which I do not want.
Thanks.
I'm afraid this is not something you can tweak just in your client-side code. In order for cross-origin requests to work, you need to set an http response header: it's the server, who serves the resource, who will need the change, not the client side code from angularJs.
I believe that you should update your question stating what your server side language is and how are you handling http requests in the server side. As far as I know, just adding a header like:
Access-Control-Allow-Origin: http://client.domain.com
In your responses will do the trick. Where client.domain.com is the domain of your client, angularJs application.
when trying to $.ajax to fetch some content from other websites in my website, I got the error.
Failed to load https://www.pinterest.com/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access.
I knew if the target website didn't allow localhost:8100 to fetch the data, I cannot fetch it in the client side on the web.
However, I found that mobile app (not mobile browser, but android/ios application) does not have the issue, they can simply get the website content by their default mobile built-in HTTP get function.
Do i want to ask why mobile will not encounter CORS issue (mobile can fetch the webcontent simply by the built-in http get function)?
thanks.
CORS is enforced by the browser to fulfill the security standard they have to meet. It does not affect requests made programmatically from any language, like a curl call on bash.
This is how CORS works, based on Wikipedia:
The browser sends the OPTIONS request with an Origin HTTP header. The value of this header is the domain that served the parent page. When a page from http://www.example.com attempts to access a user's data in service.example.com, the following request header would be sent to service.example.com: Origin: http://www.example.com.
The server at service.example.com may respond with:
An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed. For example Access-Control-Allow-Origin: http://www.example.com
An error page if the server does not allow the cross-origin request
An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains: Access-Control-Allow-Origin: *
The way CORS works means it is optional. Browsers enforce it to prevent Javascript AJAX calls to perform malicious calls. But other types of consumers built by hand don't need to enforce CORS.
Think in this example:
You are the owner of somesite.com
Users authenticate to your site using the traditional cookie method
User logins into anothersite.com, built by an attacker. This site has the following code:
<script>fetch('http://somesite.com/posts/1', { method: 'DELETE' });</script>
... effectively performing a request to your site and doing bad things.
Happily, the browser will perform a preflight request when it sees a cross-domain request, and if your site does not respond saying that requests coming from anothersite.com are OK, you will be covered by default from a potential attack
This is why CORS only makes sense in the context of a browser. Javascript you send to the browser can not (at least easily) circumvent CORS because the only API that allows you to perform requests from the browser is written in stone. Additionally, there are no local storage or cookies outside of the browser.
Corolarium: Enforcing CORS is a deliberate action from the requester, or whoever is making the requests for you, not the sender. Javascript APIs in browsers enforce it. Other languages don't have the need for the reasons explained.
When running on a device, your files are served over the file:// protocol, not http://, and your origin will therefore not exist. That's why the request from the native device does not trigger CORS.
I'm trying to support cross-origin resource sharing (CORS) calls on my API written using Google Cloud Endpoints Framework v2 in Python, but I am not able to do it.
According to the documentation, CORS is enabled by default, but I can't make any calls from a different origin using Javascript, I get this:
XMLHttpRequest cannot load https://myapp.appspot.com/_ah/api/apiname/v1/events. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://fiddle.jshell.net' is therefore not allowed access. The response had HTTP status code 500.
I've tried adding response.headers like this SO question does, but it's not working either.
Does anyone know how I can enable CORS in my API?
Thanks!
The SO link you posted mentions that the CORS headers need to be sent by the server.
You have to send the http header: "Access-Control-Allow-Origin" with value of "*" or "your client domain".
You can either send this header from the Extensible Serviceble Proxy (ESP) which is part of the Google Cloud Endpoint, or you can send the http header from your server side api script.
I would recommend sending the header from the webserver, since the ESP may cache the api responses.