ERR_BLOCKED_BY_RESPONSE.NotSameOrigin CORS Policy JavaScript - javascript

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

Related

javascript get html content (page code) from url [duplicate]

I have a page with some D3 javascript on. This page sits within a HTTPS website, but the certificate is self-signed.
When I load the page, my D3 visualisations do not show, and I get the error:
Mixed Content: The page at 'https://integration.jsite.com/data/vis' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://integration.jsite.com/data/rdata.csv'. This request has been blocked; the content must be served over HTTPS.
I did some research and all I found what the JavaScript will make the call with the same protocol that the page was loaded. So if page was loaded via https then the rdata.csv should also have been requested via https, instead it is requested as http.
Is this because the certificate is self-signed on the server? What I can do to fix this, other than installing a real SSL certificate?
What I can do to fix this (other than installing a real SSL certificate).
You can't.
On an https webpage you can only make AJAX request to https webpage (With a certificate trusted by the browser, if you use a self-signed one, it will not work for your visitors)
Steps to Allow Insecure Content in Chrome
To allow insecure content on individual sites within Chrome, click on the lock icon in the URL bar, then click 'Site settings'.
There you will see a list of various permissions the page has. Choose 'Allow' next to 'Insecure content'.
Now your HTTPS site can access HTTP endpoint
I had the same issue for my angular project, then I make it work in Chrome by changing the setting. Go to Chrome setting -->site setting -->Insecure content --> click add button of allow, then add your domain name
[*.]XXXX.biz
Now problem will be solved.
You will be able to solve the error by adding this code to your html file:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />
If any solutions don't work, try this solution.
I solved the problem adding a slash at the end of the requesting url
This way: '/data/180/'
instead of: '/data/180'
As for me, I had same warning.
I fixed it at URL request.
I had excessive '/'.
Before:
const url = ${URL}search/movie/?api_key=${API_KEY}&query=${movie};
After:
const url = ${URL}search/movie?api_key=${API_KEY}&query=${movie};
I had the same problem but from IIS in visual studio, I went to project properties -> Web -> and project url change http to https
One solution here server side end point which you access via https, which then makes the call to whichever http url, and then and returns the result. In other words, making your own little HTTPS proxy to access the http resource
update core_config_data
set value='X-Forwarded-Proto'
where path='web/secure/offloader_header'
this is easy,
if you use .htaccess , check http: for https: ,
if you use codeigniter, check config : url_base -> you url http change for https.....
I solved my problem.

Dropbox Chooser direct links: Docs say they use CORS, but I get access control errors

The Dropbox Chooser documentation says that direct links permit CORS, so that you can download file content with an XMLHttpRequest. (See "Link types," near the bottom of that documentation page.)
When I test it out, however, trying to open a file from my own Dropbox, I get an error about exactly that problem:
XMLHttpRequest cannot load https://dl.dropboxusercontent.com/1/view/[REDACTED]/tiny-html-doc.html. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access.
This error message (from Chrome on Mac, version 52.0.2743.33 beta (64-bit)) seems to directly contradict the docs, which say they allow CORS.
Am I doing something wrong, or misunderstanding? Are the docs wrong, or the server misbehaving?
This seems related to this other SO question, which doesn't have an answer, but a Dropbox dev stepped in and claimed the problem was fixed. Perhaps it's not 100% fixed?
Your code (from the gist in a comment above):
Dropbox.choose
success : ( files ) ->
console.log 'Looking for', files[0].bytes, 'bytes at', files[0].link, '...'
xhr = new XMLHttpRequest()
xhr.addEventListener 'load', ->
console.log 'Got HTML starting with this:', #responseText.substring 0, 200
xhr.open 'GET', files[0].link
// The problem is the following line.
xhr.setRequestHeader 'Api-User-Agent', 'name of my app here'
xhr.send()
linkType : 'direct'
multiselect : no
extensions : [ '.html' ]
The issue is the attempt to add a custom header. This is triggering the CORS preflight request (and this header wouldn't be allowed anyway).
Removing the header by commenting out that line fixes the problem.
I ran into this error when I was trying to download images that I was previewing.
By default, <img> tags specifically request no cors headers when fetching the image. The configuration options of the request associated with that url are then cached and are going to be used instead of fetching new configurations with the cors headers.
Adding the attribute crossorigin="" to my <img> tag solved the problem by making sure the cors headers are included when requesting the image

Page loaded over HTTPS but requested an insecure XMLHttpRequest endpoint

I have a page with some D3 javascript on. This page sits within a HTTPS website, but the certificate is self-signed.
When I load the page, my D3 visualisations do not show, and I get the error:
Mixed Content: The page at 'https://integration.jsite.com/data/vis' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://integration.jsite.com/data/rdata.csv'. This request has been blocked; the content must be served over HTTPS.
I did some research and all I found what the JavaScript will make the call with the same protocol that the page was loaded. So if page was loaded via https then the rdata.csv should also have been requested via https, instead it is requested as http.
Is this because the certificate is self-signed on the server? What I can do to fix this, other than installing a real SSL certificate?
What I can do to fix this (other than installing a real SSL certificate).
You can't.
On an https webpage you can only make AJAX request to https webpage (With a certificate trusted by the browser, if you use a self-signed one, it will not work for your visitors)
Steps to Allow Insecure Content in Chrome
To allow insecure content on individual sites within Chrome, click on the lock icon in the URL bar, then click 'Site settings'.
There you will see a list of various permissions the page has. Choose 'Allow' next to 'Insecure content'.
Now your HTTPS site can access HTTP endpoint
I had the same issue for my angular project, then I make it work in Chrome by changing the setting. Go to Chrome setting -->site setting -->Insecure content --> click add button of allow, then add your domain name
[*.]XXXX.biz
Now problem will be solved.
You will be able to solve the error by adding this code to your html file:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />
If any solutions don't work, try this solution.
I solved the problem adding a slash at the end of the requesting url
This way: '/data/180/'
instead of: '/data/180'
As for me, I had same warning.
I fixed it at URL request.
I had excessive '/'.
Before:
const url = ${URL}search/movie/?api_key=${API_KEY}&query=${movie};
After:
const url = ${URL}search/movie?api_key=${API_KEY}&query=${movie};
I had the same problem but from IIS in visual studio, I went to project properties -> Web -> and project url change http to https
One solution here server side end point which you access via https, which then makes the call to whichever http url, and then and returns the result. In other words, making your own little HTTPS proxy to access the http resource
update core_config_data
set value='X-Forwarded-Proto'
where path='web/secure/offloader_header'
this is easy,
if you use .htaccess , check http: for https: ,
if you use codeigniter, check config : url_base -> you url http change for https.....
I solved my problem.

Cannot find solutions to "No 'Access-Control-Allow-Origin' header" with CouchDB

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.

Multiple 'X-Frame-Options' headers with conflicting values

Update: This works for IE but Chrome is still throwing this error.
I am attempting to i-frame a site I own by another site I own. Here is error message I am getting in the JS console on Chrome:
Multiple 'X-Frame-Options' headers with conflicting values ('AllowAll, SAMEORIGIN, AllowAll') encountered when loading 'http://subdomain.mysite.com:8080/Dir/'. Falling back to 'DENY'.
Refused to display 'http://subdomain.mysite.com:8080/Dir/' in a frame because it set 'X-Frame-Options' to 'AllowAll, SAMEORIGIN, AllowAll'.
I did a search for SAMEORIGIN everywhere I am not setting this ANYWHERE.
The main site is www.mysite.com and the other site is subdomain.mysite.com. Obviously same-origin policies keep me from doing this.
So i have set the X-Frame-Options header on my subdomain.mysite.com to "AllowAll". On the begin-request method i have added this:
HttpContext.Current.Response.Headers.Remove("X-Frame-Options");
HttpContext.Current.Response.AddHeader("X-Frame-Options", "AllowAll");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
on the page level I have added this:
<meta name="x-frame-options" content="allowall" />
In Javascript i have added this:
<script type="text/javascript">
document.domain = "mysite.com";
</script>
I am running out of things to try... Thank you in advance for your assistance.
In my case it was the anti-forgery token that was adding the header. Adding this in Application_Start stopped it from adding it:
AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
I then added the X-Frame-Options in the web.config as I needed the whole site to be in an IFrame.
Turns out MVC4 adds the header by itself (unsolicited). The only way to get around this was to explicitly remove the header.
Response.Headers.Remove("X-Frame-Options");
There may be a way to convince MVC4 not to do this but it did not service in my scores of Google queries.
Some further detail to to Mike the Tike's answer, this is added to the application_start method in global.asax.cs, where you'll need the using directive system.web.helpers
IIS might be adding a second header after yours (you can see this by pressing F12 for Developer Tools in Chrome, attempt to load the page, then click Network, and right-click on the failed page to copy the response headers to have a look).
To stop IIS from adding the header:
Run IIS Manager
Select your website
Double click the HTTP Response Headers for the application (or on older IIS, right click on the website, click Properties, then HTTP Headers)
Then you can override or remove the extra header

Categories