I am currently trying to get some documents from CouchDB with AngularJS. My server is running locally on localhost:5984, ans I cannot access it from Brackets' renderer.
The error is the following one:
XMLHttpRequest cannot load http://127.0.0.1:5984/generator/_all_docs. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:54142' is therefore not allowed access.
This error sounds well known and a real pain to deal with, and I already tried methods from this question and searched some other sources, but nothing seems to work. My CouchDB server looks like it is well configurated, with the following members inside its configuration properties:
[cors]
credentials = false
headers = accept, authorization, content-type, origin, referer, cache-control, x-requested-with
methods = GET,PUT,POST,HEAD,DELETE
origins = http://localhost
[httpd]
enable_cors = true
I do not need credentials, at the moment, to access my data, I just need to access them from AngularJS. I would like to know what did I do / where did I go wrong, and if ever I did something wrong with my configuration or anything, how to finally allow my application to access those data. I know this is a CORS problem but as far as I tried, I found no way of doing so.
Thank you in advance !
EDIT
I am using CouchDB 1.6.1 and AngularJS, with Windows Seven. I did not try on other web browsers, but the problem currently happens with Google Chrome.
Okay, so I solved the problem.
The solutions proposed in this topic are correct and solved the problem, but you must not fail while editing your fail. I'll explain:
When I first tried, I forgot a 's' in 'origins', and then suppressed my mistake it from the control panel. The control panel just suppresses the value, and not the original tag. When I tried again, this time by editing manually the local.ini file, I found this line:
origin =
Which was, I guess, interfering with the good interpretation of the rest of the file.
When I removed it, everything went smoothly
Problem solved, thanks to The Head Rush which pushed me on the way to victory with his commentary.
Related
This is the image URL I got from an api
https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d
this is my HTML
<img src="https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d">
I see the image when I go to the URL, directly through the browser. But it is not showing up on my website
When I checked the Debug Console I get this error.
Failed to load resource: net::ERR_BLOCKED_BY_RESPONSE.NotSameOrigin
when I googled this the problem might be due to some CORS Policy issue.
How to load this image on my website without messing with the policy and stuff...?
<img src="https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d">
this should fix it
helmet({
crossOriginResourcePolicy: false,
})
I was getting the same error while fetching images from different api.
I fixed the error by adding crossorigin="anonymous" in image tag.
Just add crossorigin="anonymous" in your img tag like:
<img crossorigin="anonymous" src="https://example.com/image.jpg">
this should resolve the error.
You need to set cross-origin-resource-policy: "cross-origin".
If you're using helmet in your Express App.
try this:
app.use(helmet.crossOriginResourcePolicy({ policy: "cross-origin" }));
For more information read any of these CORP and HelmetJS
It's a CORS issue, and can only be solved server-side.
The response has the header cross-origin-resource-policy: same-origin which tells us that the resource can be accessed only by the same origin (when it's called inside a html page, using modern browsers)
You might host the image in another place to use it.
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)
There is a great proxy out there used just for this - bypassing a CORS block. The source code is here: https://github.com/Rob--W/cors-anywhere, and you would use it like this:
https://cors-anywhere.herokuapp.com/https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d
basically just adding the CORS-Anywhere URL before your actual image URL.
If you get rate limited by that website, try https://circumvent-cors.herokuapp.com/, this is one that I have deployed from the GitHub source code, no modifications and I do not think it should rate limit you.
The image you provided has expired, so if you were to give me an example of what API you were using to get the image, or another image blocked by CORS that maybe doesn't expire, I could properly test this and maybe find another answer, if this one doesn't work.
Cheers!
You can use helemt package
const helmet = require("helmet");
app.use(
helmet({
crossOriginResourcePolicy: false,
})
);
This way can fix ERR_BLOCKED_BY_RESPONSE. (by https://stackoverflow.com/a/71878799/12117869)
this should fix it
helmet({
crossOriginResourcePolicy: false,
})
this
BTW,if happen ERR_BLOCKED_BY_RESPONSE issue, Maybe the Reason :
It's a chrome bug. It will happen on the chrome 80 - 85 version. but it was fixed on the 86 version.
[CORS] Set preflight request mode correctly
CORS preflight request mode was set to kNoCors up until now, and with
cross-origin-embedder-policy: require-corp CORS preflights fail unless
a CORP header is attached. Fix the bug.
same issue :
https://bugs.chromium.org/p/chromium/issues/detail?id=1116990#c21
google fix commit: https://chromium.googlesource.com/chromium/src.git/+/ed257e2b7df1d3bdcd95d8687bcbd786bc48e717
This question is related to Cross-Origin Resource Sharing (CORS, http://www.w3.org/TR/cors/).
If there is an error when making a CORS request, Chrome (and AFAIK other browsers as well) logs an error to the error console. An example message may look like this:
XMLHttpRequest cannot load http://domain2.example. Origin http://domain1.example is not allowed by Access-Control-Allow-Origin.
I'm wondering if there's a way to programmatically get this error message? I've tried wrapping my xhr.send() call in try/catch, I've also tried adding an onerror() event handler. Neither of which receives the error message.
See:
http://www.w3.org/TR/cors/#handling-a-response-to-a-cross-origin-request
...as well as notes in XHR Level 2 about CORS:
http://www.w3.org/TR/XMLHttpRequest2/
The information is intentionally filtered.
Edit many months later: A followup comment here asked for "why"; the anchor in the first link was missing a few characters which made it hard to see what part of the document I was referring to.
It's a security thing - an attempt to avoid exposing information in HTTP headers which might be sensitive. The W3C link about CORS says:
User agents must filter out all response headers other than those that are a simple response header or of which the field name is an ASCII case-insensitive match for one of the values of the Access-Control-Expose-Headers headers (if any), before exposing response headers to APIs defined in CORS API specifications.
That passage includes links for "simple response header", which lists Cache-Control, Content-Language, Content-Type, Expires, Last-Modified and Pragma. So those get passed. The "Access-Control-Expose-Headers headers" part lets the remote server expose other headers too by listing them in there. See the W3C documentation for more information.
Remember you have one origin - let's say that's the web page you've loaded in your browser, running some bit of JavaScript - and the script is making a request to another origin, which isn't ordinarily allowed because malware can do nasty things that way. So, the browser, running the script and performing the HTTP requests on its behalf, acts as gatekeeper.
The browser looks at the response from that "other origin" server and, if it doesn't seem to be "taking part" in CORS - the required headers are missing or malformed - then we're in a position of no trust. We can't be sure that the script running locally is acting in good faith, since it seems to be trying to contact servers that aren't expecting to be contacted in this way. The browser certainly shouldn't "leak" any sensitive information from that remote server by just passing its entire response to the script without filtering - that would basically be allowing a cross-origin request, of sorts. An information disclosure vulnerability would arise.
This can make debugging difficult, but it's a security vs usability tradeoff where, since the "user" is a developer in this context, security is given significant priority.
I finally understood where I was coming from a problem that I could not understand about the recovery of the Location of my header.
I found on this page that the problem comes from CORS. I need to specify: Access-Control-Expose-Headers: Location.
However after looking at several forums I still do not understand where I have to put: Access-Control-Expose-Headers: Rental.
Can you help me understand please? Note that I work with ReactJs.
Do you actually NEED access to the Location header? Is there any way to achieve what you want without it? Your redirects should still function just fine - it's simply that by not being 'exposed' (via the Access-Control-Expose-Headers: Location) response header, you can't do anything with it in your client-side JavaScript.
I don't know if this is a duplicate post or not, sorry if it is. I'm using jquery.getJSON to load a json on my server which works just fine. Although, if I try and load a json file on a different server it doesn't work. I know I don't have any code here (because there's not much point) but I just want to know if I'm using it wrong or if it isn't supposed to load external files. I'm using the iOS Safari browser if that effects anything.
EDIT: I've looked at the console (idk what the error thing really means, it's just red with an x by the url it's trying to get the json from) and it looks like it's not actually receiving the data. Plus, do remember I'm on iOS, not desktop so I couldn't look at the console in the "Develop tab :P
EDIT 2: Great! I think I got it working! http://skitty.xyz/getJSON/
You're most likely encountering a path issue; the purpose of $.getJSON is to acquire data via http GET request so yes, it is intended to work remotely. To diagnose your issue, make certain you can access the json file in your browser first: http://domain.com/my_data.json. If that works, use that as the URL you pass into $.getJSON:
$.getJSON( 'http://domain.com/my_data.json', function(data) {
// do something with your data
});
http://api.jquery.com/jquery.getjson/
jquery.getJSON uses ajax which is all about external resources. Here's a couple things to check for if it's not working on an external resource:
1: Is the path you specified correct? The usage is jquery.getJSON(path, callback). The path should be something you can just drop in your browser and see. If an incorrect path is your problem, you'll see a 404 in the console.
2: Is the resource http and your site https? Non-secure resources on secure pages will get blocked by browser security features. You'd see a error to this effect in the console.
3: Is CORS (Cross-origin resource sharing) enabled for your site on the external resource? Servers will sometimes use a whitelist of IPs and domains to determine what origins are allowed to make requests of it. You'd also see an error to this effect in the console.
There probably some other things to look for but this is where I'd start.
Also, by all means, use the debugging features of Safari to LQQK at the actual HTTP data-streams that are passing back-and-forth in response to what you're doing. (You might need to click on a preference to see the "Develop" menu, which will take you to "Show Web Inspector" and its Network tab.)
This approach will instantly answer many questions that a JavaScript-centered approach will not so-readily tell you. (And of course, you can look at the JavaScript console too ... and at the same time.) "The actual data streams, please." Safari will tell you "exactly what bytes" your app actually sent to the server, and "exactly what bytes" the server sent in return. "Priceless!™"
Are you saying you are using jquery ajax request to load some json data from a server?
check the "not working server" has the same end point as your server.
Check if the url you want to get data from is correct.
check if console logged any errors.
Also quote from http://api.jquery.com/jquery.getjson/
"Additional Notes:
Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, port, or protocol.
Script and JSONP requests are not subject to the same origin policy restrictions."
I mocking my API using Apiary.io. But somehow I cannot read any headers from response object using angularJS. And I am sure i have at least Content-Type: application/json correctly set-up by checking in firebug. Code in Angular should read headers correctly too as i can print them when sending request to somewhere else than apiary.io...
$http.get('http://ies.apiary.io/some').then(function(response) {
console.log("ok",response.headers('Content-Type'));
},function(response){console.log("err",response);});
http://plnkr.co/edit/zMO0pXGsIdJkV0fZdBdw
It all boils down to a bug in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=608735
For CORS request, firefox is not returning anything for req.getAllRequestHeaders(), although req.getRequestHeader('Content-Type') returns properly.
Either FF bug has to be fixed or Angular must work around it (as jQuery does) or you must go deeper and use XmlHttpRequest instance directly.
This was maybe also related, but probably not the core issue:
However, few days ago, Apiary.io was not setting Max-Age in CORS headers. Thus, if you had a minimal blueprint, you might have CORS pre-flight response cached and thus subsequent requests may be disallowed even if you added additional resources to your blueprint.
Max-Age is now set to 10 seconds, so it should work properly. However, depending on your browser, pre-flight cache might still affect you. Try purging it or test this app in another browser.